STM32F407 fails to enumerate when polled periodically

[ryan-summers]

If the USB device is polled periodically, the STM32F407 fails to enumerate. To recreate, use the following example:
https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/usb_serial.rs and update the loop as follows:

let cp = cortex_m::Peripherals::take().unwrap();
let mut delay = stm32f4xx_hal::delay::Delay::new(cp.SYST, clocks);
loop {
    delay.delay_ms(1u8);
    // ... rest
}

A wireshark capture of the USB transactions with the device give some insight as to what is happening:

The first BOS descriptor request gets no response. The following 2 requests do get a response. However, then the first DEVICE_QUALIFIER descriptor gets a malformed packet as a response. Analysis of this packet seems to indicate that this is actually a BOS descriptor response from earlier.

This seems to indicate that the descriptor responses are offset by 1 improperly. It is unclear why the first BOS descriptor response fails, but initial debugging indicates it may be an improper ControlState setting. I'm still investigating root cause here.

[Disasm]

Hmm, I think I earlier faced with a situation when device responds to the first packet with garbage data. In this case, this reply is ignored by host and next reply is used as a reply to the first request.
The cause is still unclear to me, but hopefully USB driver is able to recover from the situation and resend the request.

[ryan-summers]

Further analysis and investigation has revealed this was a race condition in the processing order within usb-device. I've PR'd a fix in at rust-embedded-community/usb-device#41. We can either close this now, or we can choose to close it once the fix is merged in to usb-device and incorporated into this crate.

[Disasm]

Thank you for investigating this!
I'd like to leave the issue open, so that other people can find it before we have the fix released. I'm not sure we need to do something to incorporate the fix into the crate, because it's a bug fix and will hopefully be released as a new patch version, so cargo update will do the job.

[Disasm]

@ryan-summers Could you check/confirm that this crate works with the latest released version of usb-device? If so, we can probably close the issue.

[ryan-summers]

I have confirmed that using usb-device 0.2.6 in my application (without using patch) appears to have resolved this. I'll close this now. :)

[Disasm]

Thank you for investigating and fixing the problem!