CDC ACM IN pipe stuck as busy and claimed

[keshav-raj-trekker]

Hi all,

I have a strange issue where occasionally the CDC bulk IN (addr=0x83) endpoint gets stuck being busy and claimed.
I'm not sure how to reproduce this bug as it happens so infrequently and randomly when plugged in to my PC (ubuntu).

My device is an STM32H745XI running high speed. I have two classes running, CDC starting on interface 0 and UAC2 mono speaker on interface 2 (no feedback endpoint, I am fine adjusting I2S audio clock to keep data sync based off buffer monitoring).
When this error occurs, audio still seems to work, and replugging USB doesn't fix the issue.

Using the debugger I read the values of DIEPCTLx and the endpoint enable bit is always set to 1. Even if usb is unplugged.

On DIEPINTx the two flags set are NAK and ITTXFE.

When setting a breakpoint in the dwc2 driver dcd_int_handler function where handle_epin_irq(rhport); is called, the debugger never stops at that breakpoint indicating that the epin_irq handler is never run.

Other info:

• I am using the synopsys dwc2 driver. NOT the one under st/synopsys
• HS PHY is USB3320 over ULPI
• Endpoint 1 dedicated interrupt is not enabled.

I am running tud_int_handler(1) in the OTG_FS interrupt, and not running the HAL_PCD interrupt handler. This interrupt handler triggers another interrupt through the use of a timer to run tud_task. I did this to ensure audio processing happens at high priority in a deterministic fashion.
Whenever I call CDC functions outside of this interrupt I only disable and re-enable this one interrupt, leaving OTG_HS interrupts running always.

The average data rate on the OUT pipe is 1.2KB/s and on the IN pipe it is 8.4KB/s. My CDC RX/TX buffer sizes are both 1024 and the CDC_EP bufsize is 512.

Thanks in advance for any help provided.

[HiFiPhile]

Are you running latest version including #2333 ?

[keshav-raj-trekker]

Yup, pulled directly from master and replaced the old tusb I was using. Only change I made from there was inside dcd_init where I only unset GOTGCTL_AVALOEN in GOTGCTL to allow for unplug detection.

After running it, the same issue occurred after unplugging and replugging USB.

Below are the values of the relevant endpoint and core registers after attaching and pausing the debugger while the issue was active.

• DIEPINT3: 0x2010
• DIEPCTL3: 0x80c98200
• DAINT: 0x0
• DAINTMSK: 0x15000b

I decided to test without my modification as well and the same issue occurred.

[keshav-raj-trekker]

After some more debugging I realize that the fault is slightly different now than before when I was using my older version of tusb. I can get the fault to clear by unplugging and plugging usb back in without power cycling my device.

Also I forgot to mention that my device is self powered, and previously once the issue occurred, I could not get it to clear without resetting my whole device.

[keshav-raj-trekker]

Alright so it seems the issue has been resolved. I realized that I was still sending data to the CDC interface when the terminal was not opened. As soon as I added a check to make sure the terminal was open before sending data. The problem went away. Strangely just checking USB was connected before sending data still caused the issue.