2026-04-19 5:03 AM - last edited on 2026-04-20 3:34 AM by Andrew Neil
.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.
Solved! Go to Solution.
2026-04-25 4:45 AM
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!
2026-04-20 3:20 AM
Hello @ATeli.1
We would require minimum firmware to check the issue to instrument MSC commands :
TEST UNIT READYREAD(10)Windows may be more sensitive:
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.
2026-04-25 4:45 AM
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!