Solved
STM32U5 + ThreadX/USBX: Composite Device disconnects on Windows after 5-10 minutes
- Hello everyone,
I am developing a firmware for an **STM32U5** microcontroller using Azure RTOS (ThreadX / USBX). I am implementing a USB Composite Device with two classes: **CDC** (Virtual COM Port) and **MSC** (Mass Storage Class). The MSC is interfaced with an eMMC using an 8-bit bus for data communication.
I am facing a persistent issue that I cannot seem to resolve: the device drops the USB connection after about 5 to 10 minutes of operation. By debugging the code, I noticed that the disconnection is triggered because the device eventually calls the HAL_PCD_DisconnectCallback() function.
My main concern (and source of confusion) is that this behavior is highly OS-dependent. For instance, on my dual-boot PC, the device works flawlessly without a single disconnection on **Ubuntu 22.04**, but it consistently crashes/disconnects on **Windows**.
### What I see on Windows (Event Viewer)
Right before the disconnection occurs, Windows throws several SCSI timeout errors in the Event Viewer. Specifically, I see:
* StorDiag 507: failed non-read/write SCSI request
* CdbBytes = 000000000000 -> **TEST UNIT READY**
* StorDiag 505: failed read SCSI request
* CdbBytes = 28000000000000001000 -> **READ(10)**
* StorDiag 500: failed upper-level read
It appears Windows queries the device (BOT/SCSI commands), the device fails to respond in time, and Windows forcefully drops the connection.
### Troubleshooting steps I've already tried:
1. **Hardware Interrupt Priorities:** Increased the USB interrupt priority, setting it to 0, 1, and 2 (I know setting it to 0 is generally not recommended with an RTOS, but I tried it for debugging purposes to rule out interrupt starvation).
2. **ThreadX / USBX Memory Allocation:** Checked the sizes of the USB threads. Currently, I am allocating:
* 16 * 1024 for the USBX memory pool.
* 10 * 1024 for the USBX system stack.
* 10 * 1024 each for MSC and CDC.
* The Bulk IN and Bulk OUT thread sizes are set to 1024.
3. **Thread Priorities:** I tried lowering the USB thread priority from 20 down to several different levels to see if the scheduler was the issue.
4. **Single Class Mode:** Disabled the composite class and enabled only CDC or only MSC at a time. The issue still persists on the MSC side.
5. **Windows Power Management:** Disabled all USB selective suspend and power-saving modes on my Windows machine.
### My USB HAL Initialization parameters:
For reference, here is the basic configuration of my USB High-Speed initialization block:
.hpcd_usb_hs.Init.Sof_enable = DISABLE;
.hpcd_usb_hs.Init.low_power_enable = DISABLE;
.hpcd_usb_hs.Init.lpm_enable = DISABLE;
.hpcd_usb_hs.Init.use_dedicated_ep1 = DISABLE;
.hpcd_usb_hs.Init.vbus_sensing_enable = DISABLE;
.hpcd_usb_hs.Init.dma_enable = DISABLE;Has anyone experienced a similar BOT/SCSI timeout issue on Windows with ThreadX on the STM32U5? Are there any specific USBX timing parameters, or Cache/DMA configurations I might be missing since my dma_enable is currently set to DISABLE?
Any hints or suggestions to point me in the right direction would be greatly appreciated. Thanks in advance!
Edited to apply source code formatting - please see How to insert source code for future reference.