STM32F411, usbd_stm32f429_otgfs.c, USB_CDC_SET_LINE_CODING reads wrong value in usbd_process_eprx()

[GrantGeno]

Hello again everyone. Hoping someone has more insight than I. This again appears to be a problem with the OTG_FS reading EP0, this time as a result of the host PC issuing SET_LINE_CODING and the STM32 reading garbage (my best guess anyway). This is not so much about the SET_LINE_CODING so much as the general failure to read data stage from Endpoint 0. (This works OK on the STM32F103 using usbd_stm32f103_devfs.c driver).

Scenario is using the default CDC Loop Demo firmware on an STM32F411E-DISCO. No terminal application running - just enumeration.

• Initially the host PC (Windows) requests the current Line Coding from the CDC device (odd perhaps, but it does nonetheless).
• The firmware default values for Line Coding are returned to the host OK. [Green box]
• Then the PC sends it back. This is where the problem appears to lie. This is the write from PC to device over EP0. [Purple box]
• Finally the PC requests it once again. We can see on the USB analyzer the garbage Line Coding data the STM32 picked up. [Red box]

USB trace of above:

Here is the endpoint read usbd_process_eprx() with the bad data:

Here is that bad data being returned to our cdc_line variable:

As far as I can tell, this is the same mechanism that causes the USB HID keyboard LED report to fail as well. See my previous issue report #148

I will keep looking into it, but any help is appreciated.