USB Failed to read device descriptors and general instability

[rnd-ash]

When using the USB peripheral with default clocking state (Not tested at 120Mhz), it appears the USB implementation is extremely buggy. Linux reports multiple issues when trying to enumerate SAME51J20A connected via USB. However, after some time (Too long for my screencast), it eventually does detect the USB device correctly that SAME is implementing (In my case, CDC Serial)

Screencast_20250108_091941.webm

[ianrrees]

This could be a result of this issue - rust-embedded-community/usb-device#153

Sorry I've not gotten back in to this stuff, just keep finding interesting distractions! There's an old branch of atsamd-rs here which I believe implements the fixes but it's a bit fiddly as you need to use the same usb-device across the HAL and any USB class implementations - I suggest using Cargo's patch functionality.

[jbeaurivage]

We have also discussed on Matrix, but the fact that clocks weren't setup is also a likely cause - the USB peripheral needs a stable and precise clock source, which can come from either:

• An external crystal, or
• DFLL SOF recovery,

neither of which are enabled in the default clocking setup.

[rnd-ash]

True, but enabling the Pclk for USB seems to work 60% of the time (Im using my own branch with #808 so that USB can work with the V2 API)

let (pclk_usb, gclk0) = pclk::Pclk::enable(tokens.pclks.usb, gclk0);
rprintln!("{}", pclk_usb.freq());

Output:

48000000 Hz

Dmesg output:

[ 8980.804128] usb 3-4: new full-speed USB device number 30 using xhci_hcd
[ 8980.937330] usb 3-4: New USB device found, idVendor=16c0, idProduct=27dd, bcdDevice= 2.00
[ 8980.937344] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8980.937349] usb 3-4: Product: test DFU
[ 8980.937352] usb 3-4: Manufacturer: test
[ 8980.937354] usb 3-4: SerialNumber: 123456789
[ 8985.828748] usb 3-4: USB disconnect, device number 30
[ 8986.627503] usb 3-4: new full-speed USB device number 31 using xhci_hcd
[ 8986.760853] usb 3-4: New USB device found, idVendor=16c0, idProduct=27dd, bcdDevice= 2.00
[ 8986.760862] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8986.760866] usb 3-4: Product: test DFU
[ 8986.760869] usb 3-4: Manufacturer: test
[ 8986.760871] usb 3-4: SerialNumber: 123456789
[ 8988.305802] usb 3-4: USB disconnect, device number 31
[ 8989.290916] usb 3-4: new full-speed USB device number 32 using xhci_hcd
[ 8994.480997] usb 3-4: unable to read config index 0 descriptor/all
[ 8994.481004] usb 3-4: can't read configurations, error -110
[ 8994.597532] usb 3-4: new full-speed USB device number 33 using xhci_hcd
[ 8999.811085] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 9005.147983] usb 3-4: unable to get BOS descriptor set
[ 9010.264685] usb 3-4: unable to read config index 0 descriptor/all
[ 9010.264690] usb 3-4: can't read configurations, error -110
[ 9010.264803] usb usb3-port4: attempt power cycle
[ 9010.654549] usb 3-4: new full-speed USB device number 34 using xhci_hcd
[ 9011.784642] NVRM: nvAssertFailedNoLog: Assertion failed: rmapiLockIsOwner() @ mem_mgr.c:465
[ 9015.812884] usb 3-4: New USB device found, idVendor=16c0, idProduct=27dd, bcdDevice= 2.00
[ 9015.812895] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9015.812898] usb 3-4: Product: test DFU
[ 9015.812902] usb 3-4: Manufacturer: test
[ 9015.812904] usb 3-4: SerialNumber: 123456789

So it appears to be working 60% of the time quickly, and when it doesn't work, after the PC re-probes, it then detects it

So actually yes, @ianrrees after reading the linked issue, it appears to be that issue I'm facing rather than unstable clocks

[rnd-ash]

@ianrrees i was able to test your test usb-device crate with the latest atsamd crate (Manually patched), it works perfectly

[ianrrees]

I don't think we need to track this here anymore since the clocking aspect of this is not a HAL issue, and the usb-device aspect is already being worked (slowly) upstream.