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.

[Solartraveler]

Did you progress with your issue? I am using a STM32F405, which is using the same core usbd_stm32f429_otgfs.c.
So far i discovered:

1. I get need at least 48MHz as CPU/bus speed. At 32MHz I get data errors.
2. For an other core I learned the driver stops working as soon as I compile with -O3. -Os (using gcc from Debian 12) works.
   But there are at least other issues because I do not get the code (which works on a STM32L452) to run properly on the F405.

[GrantGeno]

I think the 48MHz is a well known requirement.

I have not made any progress due to time limitations. This issue is a show-stopper for me, and I might try and look at other stacks to see how they handle this. I prefer to use this one though, as it's nice and concise. The STM and TinyUSB ones are huge in comparison. I need a custom USB bootloader as well a main USB app, so small size is important. My best guess at this time is some issue with the FIFO readout or pointer.

[Solartraveler]

The 48MHz for the USB core is known. I mean the datasheet "To guarantee a correct operation for the USB OTG FS peripheral, the AHB frequency should be higher than 14.2 MHz." But for me it must be even 48MHz.

I don't know if the license fits you and if it is what you want - I have written an DFU USB bootloader which uploads me a program into RAM and then executes it:
https://github.com/Solartraveler/led-toybox/tree/main/src/apps/02-loader
This works fine so far.

[KimJorgensen]

It seems that the latest commit to usbd_stm32f429_otgfs.c breaks USB_CDC_SET_LINE_CODING

After reverting the logic for when to call _BST(EPOUT(ep)->DOEPCTL, USB_OTG_DOEPCTL_CNAK | USB_OTG_DOEPCTL_EPENA); I got USB_CDC_SET_LINE_CODING to work again. Before I was just receiving junk

[GrantGeno]

Thank you. Did you revert the whole file or just some modifications?

Edit: This might fix HID issues as well. I can't remember the exact issue, but I believe it was related. In any event, HID Keyboards would not get the Caps/Num/Scroll lock byte.

[Solartraveler]

I did not test the CDC sample on my platform, but later figured out I used an old version of libusb for my DFU loader which had not the mentioned commit in place. And as soon as I applied your mentioned commit, my loader stopped working. I only applied the changes in the file src/usbd_stm32f429_otgfs.c. But even without the commit, some things seem somehow to go wrong (my MSC implementation still is not fully working and there are issues as soon as I add a hub between the device an PC), but I never had the time to track this down further.

[KimJorgensen]

@GrantGeno I did this change and it worked again. No clue why.
https://codeberg.org/KimJorgensen/KungFuFlash/commit/2b606f2d858ad3467fecb2dd435c6be8d1a1da1b

[GrantMTG]

That sounds promising, thanks for sharing. I probably won't have time for a couple of weeks to try it on my end for both CDC and HID, but I am eager to get things running 100%. I have decent tools to check validation with.

[GrantGeno]

@KimJorgensen - fantastic! That fixes both the CDC Set Line Coding as well as the USB HID Keyboard's LED via Class Request 0x09 issue I was having with the STM32F411E-DISCO board projects I started and abandoned. I have not had time to run either application through USBCheck but this is great news, thank you!

See also: #148