USB OTG_FS (device mode) CDC-ACM: IN endpoint transfer complete interrupt never fires after sometime with STM32F411/STM32F413

[MSuhe]

I am working on testing libopencm3 based USB OTG FS stack for STM32F411/STM32F413. And OTG FS stack works fine to begin with without any issues. But, after a while it seems to lock-up waiting for transfer complete interrupt to fire on one of the IN endpoints.

The test script running on the PC repeatedly sends messages to the OTG device and device also sends data back. This seems to run fine for a while but eventually gets locked-up.

I have a debugger hooked and on lock-up i observe that the transfer complete interrupt on an IN endpoint never fired, causing to device to hang.

Browsing for similar issue i have come across multiple posts where people have reported similar problems and it looks like TX FIFO access has some limitations.

Can someone please shed more light on how to fix this bug. We have been debugging this for a while and haven't been successful in fixing this. Any inputs would be highly appreciated.

[waclawek.jan]

I didn't meant increasing FIFO as a solution. I don't know what's the solution.

I meant to increase FIFO only to see what's the remainder of space in FIFO (OTG_DTXFSTSx ) when the problem occurs, Also, any change in other registers when the problem occurs?

Also,

Store the intended number of writes before starting writing to FIFO to a static/global variable, so that it could be checked when the problem occurs. Similarly store the value you are writing to DIEPTSIZ for later checking (any other interesting register writes too perhaps).

JW

[MSuhe]

I did try to repeat my tests and register state is similar to what i reported previously:

1. When the lockup occurs, i notice that DIEPTSIZx is set to 0x80000 (which is packet count of 1 & transfer size of 0). So, packet is still not sent out?
2. OTG_DTXFSTSx is 0, which indicates FIFO is full. Sometimes non-zero, based on the length of frame queued to FIFO.
3. DIEPCTLx is set to 0x80888040/0x80898040 which indicates endpoint is still enabled.
4. DIEPINTx is consistently 0x2010 i.e, NAK input bit is 1 & ITTXFE is also 1.

However, this time around i added a software workaround. Wherein, if the IN endpoint stays enabled for one full second and transfer complete interrupt does not fire. I treat it as a lock-up scenario and executed below sequence:

1. set NAK on the end point.
2. Disabled the endpoint.
3. Flushed the TX FIFO's.
4. And enabled the endpoint again, and initiated a new transfer.

But the new transfer never finishes. As endpoint again goes to lock-down state where i don't see the XFRC interrupt firing.

Any inputs?? 

[waclawek.jan]

At this point, I'd perhaps use a hardware bus analyzer, and/or investigate at the host side...?

JW

[MSuhe]

I do not have a hardware bus analyzer with me, until i get one. Anything else that i can try may be?

[MSuhe]

I do not have a hardware bus analyzer with me, until i get one. Anything else that i can try may be?

[waclawek.jan]

I'm out of ideas by now... Sorry.

JW

[MSuhe]

np, thanks for your inputs.

[MSuhe]

We also tried different ways of reproducing this issue, and the easiest way to do so was by closing the host application/script while the communication between USB host and device is ongoing. So, if i abruptly close the host application and if the OTGFS device happens to have started the IN transfer it ends up in this scenario where IN transfer complete interrupt never fires.

Next, if i try to reopen the host application it does not work and OTG FS device is stuck in this state until we do a power cycle. I do not observe this issue with a different hardware platform that we have (not based on STM32 MCU though).

any ideas, how to overcome this issue?

[SKerk.1]

I know this is an old thread, but could you solve the lockup issue and determine the root cause?

I'm working with the same OTG FS peripheral and experience lockup issues ​the seem the same. If you where able to find a solution I would be very interested to know.

Thank you​