Skip to main content
G
Gretchev
Visitor II
October 9, 2025
Question

STM32H533RE — ThreadX + USBX causes threads to stop cycling

  • October 9, 2025
  • 1 reply
  • 296 views

Hello ST Community,

I’m working with the NUCLEO-H533RE. The MCU is feature-rich (three PLLs, robust comms, and onboard USB wired to a USB-C connector) and I’m running the system clock at 250 MHz. I’ve migrated the project to ThreadX (since the old USB stack isn’t provided for this part with FreeRTOS), and the USB stack is the USBX integration.

ThreadX alone comes up clean, but as soon as I enable USBX the application stalls—my threads stop cycling and the system appears to hang. I’m likely missing a configuration detail in the USBX/ThreadX bring-up.

If someone with deep experience on STM32H5 + ThreadX/USBX could point me to the typical culprits (initialization order, memory pools/stack sizes, NVIC priorities/interrupt routing, cache/MPU settings, or any H5-specific gotchas), I’d really appreciate it. Happy to share configuration snippets, clock tree, and MX-generated code if that helps.

Thanks in advance,
Val

    This topic has been closed for replies.

    1 reply

    G
    GretchevAuthor
    Visitor II
    October 21, 2025

    Resolving ThreadX + USBX causes threads to stop cycling

    Lessons Learned from the STM32H5 Workshop USBX-CDC Lab

    See https://www.youtube.com/watch?v=LdY2bieaPwk

    Background

    Thanks to the STM32H5 workshop, specifically the "09 USB - USBX-CDC lab (experts)", a recurring issue was identified where ThreadX would crash as soon as USBX was enabled. This problem was traced back to memory allocation settings within the USBX framework for STM32H5 microcontrollers. 

     

    Identified Solution

    The root cause of the crashes was insufficient memory allocation for the USBX device and system stack. The solution was to:

    • Increase the UXDevice memory pool size: Set to 16*1024 bytes in the Memory Configuration.
    • Increase the USBX Device System Stack Size: Set to 10*1024 bytes under USBX Device Common Init.

    Both of these parameters are adjustable in the USBX Mode and Configuration settings. Once these values were increased, ThreadX ceased to crash, allowing the USBX-CDC code to operate reliably.

    Implications for Developers

    The discovery highlights the importance of appropriate default settings in embedded software frameworks. Many developers may have spent considerable time troubleshooting this issue due to the default values being too low for practical use cases. If the defaults were set more appropriately, countless hours of debugging could have been avoided.

    Recommendations

    • Check memory pool and stack size settings: Always review and adjust these parameters when working with USBX and ThreadX on STM32H5 devices.
    • Feedback to framework maintainers: Consider reporting default value issues to the maintainers of STM32Cube and USBX so that future releases can provide more suitable defaults for common applications.
    • Share solutions with the community: Documenting and sharing such fixes can save fellow developers significant time and frustration.

    Conclusion

    The time invested in troubleshooting memory allocation issues in the STM32H5 USBX-CDC lab serves as a reminder of the critical role of configuration parameters. By adjusting the UXDevice memory pool size and the USBX Device System Stack Size, stability was restored. Developers are encouraged to be proactive in reviewing defaults and sharing knowledge to improve the development experience for all.

     

    Terms & ConditionsAccessibility statement