ThreadX on STM32: RAM nearly filled up

[Ingenieer]

I'm currently starting to use ThreadX / AzureRTOS on a STM32 Nucleo-H723ZG (STM32H723ZG MCU).

I noticed that when loading the Nx_TCP_Echo_Server / Nx_TCP_Echo_Client projects from CubeMX, the RAM gets filled up pretty much to the top, which makes me wonder, how I'm supposed to add my own code and data here.

Since I'm pretty new to RAM partitioning, RTOS and similar, I don't have a perfect feeling for what is wrong or right and how to proceed (and if it is a problem at all).

Nevertheless I wonder, if maybe using a different way of partitioning the RAM or by dropping some non-necessary code-parts, the RAM could be freed-up.

Or a different way of thinking:

Since RAM_D1 got filled, but _D2, _D3 and DTCMRAM are pretty much empty, is there a way to use the free RAM for my own purposes (I would like to let SPI and ADC processing run via DMA, so this needs a place to go ....)

Hope my questions are not too confusing ;)

The system has the following amount of RAM, according to STM:

"SRAM: total 564 Kbytes all with ECC, including 128 Kbytes of data TCM RAM for critical real-time data + 432 Kbytes of system RAM (up to 256 Kbytes can remap on instruction TCM RAM for critical real time instructions) + 4 Kbytes of backup SRAM (available in the lowest-power modes)" (see STMs STM32H723ZG MCU product page)

Down below you'll find screenshots of the current RAM usage, for RAM_D1 especially .tcp_sec eats up most of the RAM.

--> Can .tcp_sec be optimized or kicked-out?

If tcp means here the tcp protocol, maybe this can be a way to optimize this, since I'm not sure whether I need a handshake etc., maybe UDP is sufficient (and faster for the ADC data streaming) ... what do you say?

Edit:

The linker-file shows, that there .tcp_sec (NOLOAD) is written ... is NOLOAD maybe a hint on a "placebo" RAM occupation (pre-allocation / reservation, but no actual usage?)

Linker-script extract:

/* User_heap_stack section, used to check that there is enough RAM left */
 
 ._user_heap_stack :
 
 {
 
   . = ALIGN(8);
 
   PROVIDE ( end = . );
 
   PROVIDE ( _end = . );
 
   . = . + _Min_Heap_Size;
 
   . = . + _Min_Stack_Size;
 
   . = ALIGN(8);
 
 } >RAM_D1
 
 
    .tcp_sec (NOLOAD) : {
 
 
   . = ABSOLUTE(0x24048000);
 
   *(.RxDecripSection)
 
 
   . = ABSOLUTE(0x24048060);
 
   *(.TxDecripSection)
 
 
 } >RAM_D1 AT> FLASH

For context:

I am developing a "system controller", where my plan is to have it running a RTOS, which manages the read-in of analog values, writing control messages via SPI to two other STMs of the same kind and communicating via Ethernet to my desktop application.

The desktop application is then in charge of post-processing the digitized analog values and sending control messages to the system controller. In the best case the system controller digitizes the analog signal on ADC3 with 5 MSPS (at probably 6 Bit resolution = 30 MBit/s) and sends that data hickup-free to my desktop application.

-> Is this plan possible on this MCU?

I tried to buy a higher (more RAM) version of the nucleo I've got, but due to shortages this one is the best one I was able to get.

For the RTOS I'd like to stick with ThreadX, since FreeRTOS support in STM32IDE seems to be phased out now, after ThreadX was employed as the RTOS by STM.

(I like the easy register configuration using CubeMX/STM32 IDE, hence my drive to use that SW universe ... if there are good reasons to use a different RTOS, tell me :) )

Thank you for your time!

[Semer CHERNI]

Hello @Ingenieer​ 

I suppose that what you are looking for is the Linker option:

> --enable-non-contiguous-regions

You also needs to modify the linker script to tag the sections which alternatively can be used if the current section is running out of space. This is quite well explained in the Linker manual:

Inside CubeIDE > Help > Information Center > STM32CubeIDE manuals > C/C++ Linker > Page 5 (or 11 depending on how you look at it :-D). Or just search in the manual for the first search hit for "--enable-non-contiguous-regions"

I hope this resolve you issue; waiting for your feedback.

Kind regards,

Semer.