STM32: USB: USB CDC IN Endpoint stuck forever after receiving Clear feature - endpoint halt request

[ptrcr]

Describe the bug

I have a stm32wb55rg based device with enabled USB CDC, that is connected to PC over a USB hub. After the device reset and successful enumeration in host system, application is opening a port to communicate with the device over CDC. During enumeration process, the device schedules sending the ZLP packet.
Normally, after opening a serial port, the host starts polling the In Endpoint right away, reads the ZLP and communication proceeds without any issues. But sometimes before the host starts polling it sends 'Clear feature - endpoint halt' request first, and then starts polling the IN Endpoint.
This request is handled by calling usb_dc_ep_clear_stall. Underneath, it causes setting the endpoint's status to NAK, which effectively cancels any pending transfer without releasing associated resources, that is the queued ZLP packet transfer and endpoint's write semaphore. As a result, it is impossible to schedule any new transfer, because there is an unfinished transfer that due to NAK status will never be completed.

To Reproduce
This situation seems to happen randomly from around once per 5 to once per 100 following cycles:

1. Reset the device
2. Open serial port from host application
3. Send any message from the device to host over CDC

Expected behavior
Message sent from the device to the host should be read by the application that opened the serial port.

Impact
Unable to perform two way communication with the device. Messages from the host to the device are sent successfully.

Logs and console output
The following screenshot presents logs from the described situation. The host sends request b'0201000082000000' and starts polling IN endpoint, but the status is NAK forever, ZLP packet is not read.

Environment (please complete the following information):
I was only able to reproduce this bug on a PC with Debian GNU/Linux 11 bullseye 5.10.0-28-amd64 and the device connected over a USB hub (reproduces with a few different USB hubs).

Additional context

[github-actions]

Hi @ptrcr! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[ptrcr]

I opened a PR that works for me: #89982

[jfischer-no]

But sometimes before the host starts polling it sends 'Clear feature - endpoint halt' request first, and then starts polling the IN Endpoint.

It would not happen without reason. Your tracelog does not show what is really going on, please add a tracelog since the bus reset or Set Configuration request. Kernel cdc-acm driver does not randomly call usb_clear_halt(acm->dev, acm->in).

[ptrcr]

Below is a tracelog with transfer level, starting from the reset.

---

For a reference, below is the same tracelog when the issue does not occur. All Control transfers look the same, except for the Clear Halt request.

I put a '*' next to a transfer that needs a little explanation as it might be misleading. This transfer is actually a first device->host transfer after ZLP and a timestamp associated with this transfer is a timestamp when polling of the IN Endpoint stared after reading the ZLP. LeCroy software associated ZLP packet to transaction that started before the device reset (when the host started polling the Endpoint) - this is just how this software sorts transfers. This is not present in the following logs (packet level), ZLP can be found instead.

---

Below is the same tracelog (when the issue occurs) on packet level. Hosts starts polling on the IN Endpoint 0x02 after sending Clear halt request.

---

And for reference, the same tracelog on packet level, when the issue does not occur. Polling the IN Endpoint starts after the first SET_LINE_CODING request. Examining the logs side by side does not give any differences in transactions, except for the IN Endpoint polling, and Clear halt request.

[jfischer-no]

@ptrcr Thanks.
Are you using samples/subsys/usb/cdc-acm sample to reproduce it? If not, could you please try?
On the host side, could you please enable debug messages if possible (echo 'file cdc-acm.c +p' > /sys/kernel/debug/dynamic_debug/control) and post them here? Thanks.

Checking if the endpoint is halted should prevent the lock you observed. Could you please test the change below?

diff --git a/drivers/usb/device/usb_dc_stm32.c b/drivers/usb/device/usb_dc_stm32.c
index 16b91470dee..4fcefd7a129 100644
--- a/drivers/usb/device/usb_dc_stm32.c
+++ b/drivers/usb/device/usb_dc_stm32.c
@@ -852,6 +852,10 @@ int usb_dc_ep_clear_stall(const uint8_t ep)
                return -EINVAL;
        }
 
+       if (!ep_state->ep_stalled) {
+               return 0;
+       }
+
        status = HAL_PCD_EP_ClrStall(&usb_dc_stm32_state.pcd, ep);
        if (status != HAL_OK) {
                LOG_ERR("HAL_PCD_EP_ClrStall failed(0x%02x), %d", ep,

[ptrcr]

@jfischer-no I was able to reproduce it using samples/subsys/usb/cdc-acm on nucleo_wb55rg board just with minor changes that made it easier to reproduce it (if 'R' is sent to the device, it performs a reset after 250ms):
cdc-acm-sample.patch

I enabled debug messages you asked for and the logs when CLEAR HALT is sent are following:
clear_halt_cdc_acm.txt

And for a reference, logs when there is no CLEAR HALT:
port_open_ok_cdc_acm.txt

Regarding the change you proposed, I tested it and verified that it solves the issue. However I have concerns regarding scenario when the host sends SET FEATURE ENDPOINT HALT and then CLEAR FEATURE ENDPOINT HALT. I think it would also result in endpoint lockup.

[jfischer-no]

@jfischer-no I was able to reproduce it using samples/subsys/usb/cdc-acm on nucleo_wb55rg board just with minor changes that made it easier to reproduce it (if 'R' is sent to the device, it performs a reset after 250ms): cdc-acm-sample.patch

I enabled debug messages you asked for and the logs when CLEAR HALT is sent are following: clear_halt_cdc_acm.txt

PC with Debian GNU/Linux 11 bullseye 5.10.0-28-amd64

Can you please try a less ancient kernel, version 6.. (I cannot reproduce it).

However I have concerns regarding scenario when the host sends SET FEATURE ENDPOINT HALT and then CLEAR FEATURE ENDPOINT HALT. I think it would also result in endpoint lockup.

If that matters, you should probably use device stack next. Though, I cannot promise that it will work seamlessly on this platform.

[ptrcr]

@jfischer-no Unfortunately I am able to reproduce it only on this particular machine with this kernel version. The fix you proposed is working on my setup, so I updated the related PR: #89982