cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U5 - USBX memory defaults woefully small

dmarks-ls
Associate III

TL;DR - adding USBX and the USB CDC device class to my STM32U5 TouchGFX project causes it to fail during initialization, because the default memory settings are woefully inadequate.

I have a TouchGFX project running on an STM32U5G9J-DK2 using ThreadX.  The TouchGFX component tosses up a splashscreen, and I have other tasks running, including a debug task putting out UART data.  So that all works fine.

What doesn't work is when I add USBX and a simple USB CDC device class to the project.  I can add it using CubeMX, but when I build and run it, it dies during initialization because of memory allocation issues.  I would at least expect it to run out-of-the-box when adding it to a new or existing project.

Here are my steps to reproduce the failure:

  1. Make a workspace directory (I called mine C:\ST\workspace\touchgfx_usb_issue).
  2. Open TouchGFX, create a new project, select STM32U5G9J Discovery Kit 2 running ThreadX, select the workspace directory as the "Application Directory", and set "Application Name" to "usb_issue", and click Create.
  3. Drop a green box onto the canvas so there's something there, then click Program and Run Target.  Confirm that the green box/whatever appears on the screen.
  4. Open STM32CubeIDE, and switch to the workspace directory.
  5. Select Import / Existing projects into workspace, select the "usb_issue" directory in the workspace directory.  Confirm that "STM32U5G9J-DK2-ThreadX" appears as the project name.  Finish importing.
  6. Click the hammer to build the project, then click the green bug to debug and run the project.  Confirm that the green box/whatever appears on the screen.
  7. Open the IOC (CubeMX) file.  Under Pinout and Configuration / Connectivity, select USB_OTG_HS, then under Mode / Internal HS Phy, select "Device Only".  Confirm that PA11 and PA12 are now selected for USB.
  8. Select the Clock Configuration tab, and decline to run the clock issue solver.  Scroll to the bottom, and for "OTG HS Clock Mux", select "HSE".  Confirm that "To OTG Mux (MHz)" shows 16 MHz.
  9. Go back to Pinout and Configuration, and under Middleware, select USBX.  Check "Core System", then under "UX Device HS", select "Device CoreStack HS".  Then under "Device Class HS", select "CDC_ACM".  Leave all USBX (UX_...) settings at their defaults.
  10. Save the IOC.  This should trigger generation of source code.
  11. Click the hammer to build the project, then click the green bug to debug and run the project.  Click Resume (green right arrow), and observe that the green box has not appeared on the screen.
  12. Click Suspend (pause symbol), and observe that the program is stopped in the section "MX_USBX_Device_Init_Error".

USBX init failsUSBX init fails

Tracing into the application, the call to ux_device_stack_initialize() (app_usbx_device.c, line 117) is failing because a call to _ux_utility_memory_allocate() (ux_device_stack_initialize.c, line 175) is failing.  There appears to be only 24 bytes left in the USBX device driver memory pool, which is what's left over from the 512 bytes of "USBX Device System Stack Size".  That's not enough to allocate even the first thing that ux_device_stack_initialize() wants to create.

If I put a breakpoint inside _ux_utility_memory_allocate() and add up all the memory that's allocated (including three allocations of UX_SLAVE_REQUEST_DATA_MAX_LENGTH == 2048), it totals 7124 bytes.  This value dictates the minimum "USBX Device System Stack Size".  This value plus the "USBX Device Application Thread Stack Size" (default 1024 bytes) must come in under the "UXDevice memory pool size".  So if I set my USBX Device System Stack Size to 8000 bytes, and set the UXDevice memory pool size to 10000 bytes, then my application actually comes up.

So bottom line... please try to ensure that out-of-the-box configurations for components like USBX are able to function when built, instead of sending users down a rabbit hole.  Thanks.

Dana M.

4 REPLIES 4
FBL
ST Employee

Hi @dmarks-ls 

Default settings in STM32CubeMX are designed to provide a starting point but often do not account for the specific requirements of middleware components like USBX. It's up to the user to define memory pool size and USBX device stack size.

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.


Not a good answer.  Hunting in Debug for a poorly issued "starting point" is like saying: "good luck making the device work - you'd better be an expert."  I ran into this issue as well with the code.  Guessing what the Pool and Stack *should* be is wrong.

I completely understand that relying on default settings without clear guidance on middleware parameters such as the USBX memory pool size and device stack size can be frustrating. However, since memory requirements depend heavily on the specifics of your application which you haven’t provided @knights-of-ni , I’m unable to give a precise estimation for your memory footprint.

That said, I shared some points on where to focus your efforts. The best approach is to adjust the pool sizes incrementally while carefully monitoring system stability to find the optimal configuration for your use case. @dmarks-ls already found out that increasing Device System Stack Size to 8000 bytes, and set the UX Device memory pool size to 10000 bytes fixed the issue. 

USBX Device Memory Pool Size ≥ 10 KB Must cover all USBX allocations plus margin
USBX Device System Stack Size ≥ 8 KB Must cover internal USBX stack and buffers
USBX Application Thread Stack 1 KB (1024 bytes) Adjust if your application threads require more
ThreadX Byte Pool Size ≥ 32 KB (example) To cover all thread stacks and RTOS objects

Additionally, 

Additionally, in the STM32CubeMX interface, it is mentioned, the USBX Device System Stack Size must be configured between 512B and 256 KB  and should always be less than the USBX memory pool size.

Typical recommended stack sizes per USB class are:

  • HID: 4 KB
  • Storage: 5 KB
  • DFU: 4 KB
  • CDC ACM: 6 KB
  • CDC ECM: 34 KB
  • Video: 6 KB
  • RNDIS: 34 KB
  • MTP: 12 KB
  • Printer: 3 KB
  • CCID: 8 KB
  • Composite: sum of all required class sizes

Even USBX documentation provided by Eclipse provides guidelines to initializes USBX memory resources starting with 128 KB of memory. Also, here is a demo in ThreadX documenation to initialize these system resources and show how to allocate memory pools and create threads with appropriate stack sizes

 @knights-of-ni Feel free to share more details about your issue in new thread if you need further assistance or to share any ideas or questions to improve our documentation and examples to help users configure ThreadX and USBX. If you have any suggestions or specific areas where you think we could enhance the guidance or examples, 

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.


I hope I did not offend you FBL.  

The reference link is certainly helpful.  I was able to address the memory limitation issues with the project - I think that the emphasis was on modifying the MX software to add a note or link to the documentation you have provided above, not that the S/W was unusable.