STM32F413/L476: USB_OTG_FS (CDC-ACM) (device-mode): IN endpoint lock-up

[MSuhe]

We have been working on developing a USB dongle based on STM32F413/L476 which acts as a CDC-ACM serial device. We mostly have everything up and running expect for an issue with USB which shows up sporadically and details are as below:

• USB CDC-ACM interface enumerates fine.
• Communication with host over USB is also fine.
• The host application keeps sending data over USB to dongle. And dongle in-turn sends back application specific responses.
• But after a while, we see that USB communication is no more ongoing. And on a closer, look we found that it is the IN transfers from the USB OTG device that are blocked.
• From the IN endpoint register state, it looks endpoint is enabled and transfer is ongoing. But, for some reason Transfer complete interrupt never fires anymore. Causing the lock-up.
• To get more insights into the issue, i also tried capturing the USB traffic using Wireshark. And when the issue shows up, i see that USB device is sending URB_BULK_in packets to host with status set to "Broken pipe (-32)". Which is not the case otherwise.

Can anyone from the community please share inputs on the above issue. We have been debugging this for a while already and any help would be much appreciated.

[Vangelis Fortounas]

• "The host application keeps sending data over USB to dongle. And dongle in-turn sends back application specific responses."

it seems like synchronization issue between Tx and RX.

usually this hapens when transmit inside Rx callback.

[MSuhe]

Hi Vangelis,

Thanks for your inputs, much appreciated. I have below inputs from my side.

• ​We are running the USB stack from interrupt handler.
• The bulk OUT endpoint is 1 and bulk IN endpoint is 2.
• Whenever host sends data to bulk OUT endpoint, we just copy the data from HW FIFOs to application buffers In the RXFLVL handler.
• And on getting XFRC interrupt on IN endpoint, we check if we have any more data to be sent. If yes, we copy the data to IN endpoint FIFO and start the transfer. And if not we just leave the callback handler.​
• The synchronization scenario that you mentioned can arise, if we have both RXFLVL and XRFC interrupt at the same time.

So, what can I do to overcome the issue, please share your inputs. As mentioned in my post, the issue is IN endpoint locks up waiting for XFRC interrupt to fire.

Again thanks for your inputs.​

Regards,

Suhel​

[MSuhe]

Guys, can anyone share there inputs?

[Vangelis Fortounas]

Make some code and do not transmit inside RX callback (Handler Mode).

Tranmission must take place in Thread mode. (in some circumstances is possible).

Inside the callback take the data when receive something and set an RX_Flag that is continuously checked by a loop in thread mode. Inside this loop process the data and make the transmission.