I'm seeing a repeatable bug which appears on the usb-echo sample when used with a Feather M0 as well as our custom hardware. If I trigger a scan of the USB descriptors of an attached device using lsusb -v -D , it will frequently fail to fetch one or more of the mfgr/product/serial string descriptors. A bus analyser shows that the relevant SETUP transaction is ACKed but then ignored. Adding debugging to atsamd/hal/../usb/bus.rs reveals that its read() function is being called with an zero-sized buffer when a SETUP is present, causing a BufferOverflow to be reported. The caller turns out to be the ControlState::StatusOut match in control-pipe.rs/handle_out(). Simply omitting the line
self.ep_out.read(&mut []).ok();
makes the descriptors read much more reliably, but causes other problems in our application, so its clearly not the correct answer.
ianrrees
commented
2 years ago
I'm seeing a repeatable bug which appears on the usb-echo sample when used with a Feather M0 as well as our custom hardware. If I trigger a scan of the USB descriptors of an attached device using lsusb -v -D, it will frequently fail to fetch one or more of the mfgr/product/serial string descriptors. A bus analyser shows that the relevant SETUP transaction is ACKed but then ignored. Adding debugging to atsamd/hal/../usb/bus.rs reveals that its read() function is being called with an zero-sized buffer when a SETUP is present, causing a BufferOverflow to be reported. The caller turns out to be the ControlState::StatusOut match in control-pipe.rs/handle_out(). Simply omitting the line
self.ep_out.read(&mut []).ok();
makes the descriptors read much more reliably, but causes other problems in our application, so its clearly not the correct answer.