cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U5 + ThreadX/USBX: Composite Device disconnects on Windows after 5-10 minutes

ATeli.1
Associate III
  • 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.

1 ACCEPTED SOLUTION

Accepted Solutions
ATeli.1
Associate III

Hi! I found out the problem and is really similar to the one explained here: https://community.st.com/t5/stm32-mcus-embedded-software/unimplemented-usbx-storage-scsi-causes-stall/td-p/887716

The main issue is that USBX middleware do not support some command and this send the USB in a STALL state. In particular some Windows DELL computers send the SCSI command 0x85.

Hope that this post can help other people!

 

 

View solution in original post

2 REPLIES 2
FBL
ST Employee

Hello @ATeli.1 

We would require minimum firmware to check the issue to instrument MSC commands :

  • entry/exit of SCSI command handlers
  • storage read/write completion
  • TEST UNIT READY
  • READ(10)

Windows may be more sensitive:

  • polls MSC more aggressively,
  • expects stricter BOT timing..

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.




Best regards,
FBL
ATeli.1
Associate III

Hi! I found out the problem and is really similar to the one explained here: https://community.st.com/t5/stm32-mcus-embedded-software/unimplemented-usbx-storage-scsi-causes-stall/td-p/887716

The main issue is that USBX middleware do not support some command and this send the USB in a STALL state. In particular some Windows DELL computers send the SCSI command 0x85.

Hope that this post can help other people!