Hi,
I'm trying to resolve a issue I see occasionnaly where my USB CDC-ACM device fails to be detected by Windows/Linux host as it is not responding to the first device descriptor request until the system is fully reset.
The scenario:
- STM32U575 (can repro this issue on Nucleo-U575 eval board too)
- USB-C port on the device, but no OTG/PD, just running it as USB2
- Device mode only
- CDC-ACM stack using latest ST HAL, ThreadX and USBX (FW package 1.3.0)
In normal product usage, the problem only manifests itself rarely so is hard to debug, but I have found I can recreate the scenario by introducing a breakpoint or delay into the HAL ISR routine for the OTG_FS interrupt. Steps:
- Have the device working normally.
- Unplug the USB cable
- Place a breakpoint in the HAL_PCD_IRQHandler within the `stm32u5xx_hal_pcd.c` file. I usually go for the USBRST interrupt (~line 1383).
- Plug cable back in.
- When breakpoint is hit, simply resume immediately then remove the breakpoint.
- From this point on, the USB device will no longer be recognised by the host, even if you unplug the USB cable and plug it back in.
Examining the packets tx/rx on the host side we can see that everything is ok up until the point of the host requesting the device descriptor to which the device fails to respond. The PC host keeps retrying every few seconds until it eventually gives up.
Looking at the interrupts raised by the OTG_FS peripheral, we can see:
- USBRST - reset
- ENMDNE - enumeration complete, speed = FS. This results in a call to USBX ux_stack_connect.
- RXFLVL - rx data - this is the first part of the SETUP phase where we receive the device descriptor request (BCNT=8 bytes).
- Next, in normal scenario, I get another RXFLVL with BCNT=0 which indicates end of the setup transaction at which point it proceses the message and ends up going into `ux_device_stack_descriptor_send` and that leads on to IEPINT - endpoint 0 xfer complete, etc.
- In bad situation, we get the one RXFLVL interrupt then nothing for 4s before host sends USBRST.
I don't have a h/w sniffer to see what is going on on the wire, but it seems the first setup packet is not being ACKed so the host never sends the completion packet.
I can understand that interrupting the normal interrupt flow can mess the session up, but what I can't resolve yet is how to recover from this situation. Once its happened it is game over until I fully reset the processor.
Again, this is easily repoducable using the Cube example project Ux_Device_CDC_ACM with the Nucleo-U575ZI-Q evaluation board.
Any help on how to recover this situation would be greatly appreciated. I can't see anything obvious in the OTG_FS status registers but I might have missed something!
