cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U5 ThreadX Application Memory Pool size limitation

ocean_rse
Associate II

I've been working on a project based on the STM32U575 Nucleo board for some months now. I just updated STM32CubeIDE yesterday and I noticed the ThreadX memory pool size option in "Middleware and Software Packs -> THREADX ->Memory Configuration" has shrunk to a max of 201.216K bytes. Previously it was something a little bit larger, can't remember the exact number but at least a few K larger.

The application I am writing needs nearly all the available memory on the chip, north of 700K. Since I've started this project, I've been manually updating the definition for the TX_APP_MEM_POOL_SIZE in app_azure_rtos_config.h to something suitably large after making changes in CubeMX and haven't noticed any issues, but I've always wondered why this memory pool size limitation is imposed. The new update and shrinking of the max mem pool size has only served to remind me of this.

Can anyone explain exactly why this memory limit is so small in comparison to available ram? I've read the documentation from STM and Microsoft for ThreadX many times now and have not found anything that explains why there is a memory size limitation in place that is much smaller than available ram.

1 ACCEPTED SOLUTION

Accepted Solutions
MWB_CHa
ST Employee

Hi @ocean_rse 

The memory footprint optimization is a major concern for multiple customers. So, in STM32CubeMX, we try to provide by default the minimum functional size in order to reduce the footprint as much as possible. 

Then of course, users might increase the size depending on their application usage.

If an arbitrary large size is provided by default, some customers might find that low SRAM space is remaining available and might face issues implementing their application if they don't think changing the default memory allocation.

I hope this answers your question. 

View solution in original post

1 REPLY 1
MWB_CHa
ST Employee

Hi @ocean_rse 

The memory footprint optimization is a major concern for multiple customers. So, in STM32CubeMX, we try to provide by default the minimum functional size in order to reduce the footprint as much as possible. 

Then of course, users might increase the size depending on their application usage.

If an arbitrary large size is provided by default, some customers might find that low SRAM space is remaining available and might face issues implementing their application if they don't think changing the default memory allocation.

I hope this answers your question.