Dual ucHeap memory regions.

[Dmivaka]

Hi!

I'm making a project based on FreeRTOS in STM32CubeIDE.
Build Analyzer shows two memory regions named ucHeap in RAM. I believe these two objects come from the custom_memory_manager.c and FreeRTOS's heap4.c. Is it normal these two objects coexist? Why are their sizes defined in FreeRTOS config? Why do they have the same name?

Thanks!

[DrMarkusKrug]

Hi,
no having two times ucHeap, that's not correct and also a little bit surprising that the whole thing is compiling and propably even running.
In the file file custom_memory_manager.c there should be a 'extern' statement declaring ucHeap. So it should look like
extern unsigned char ucHeap[];
In the file heap_4.c the ucHeap[] should be declared.

Best Regards
Markus

[Dmivaka]

Hi @DrMarkusKrug,
Seems like a correct way to declare heap is to delete "static" attribute of ucHeap in custom_memory_manager.c:
uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
and then define
configAPPLICATION_ALLOCATED_HEAP=1
in project settings. This way FreeRTOS's heap_4.c is kept unmodified and can be re-generated by CubeMX without deleting changes.
Thanks a lot!

[DrMarkusKrug]

Hi,

good to hear it's working on your side.
On my STM32L4 with comparable small RAM size (64KByte) I decided to setup all publisher, node, subscriber before starting FreeRTOS. This will allocate these elements on the heap instead of the Taskheap (represented by ucHeap[] array). I'm still not sure if the memory allocation inside the rcl_* init functions has some problems with the way FreeRTOS is dealing with the Taskheap and therefore is corrupting it. Certainly, for the allocation I'm using standard malloc/free/realloc/calloc functions and not the ones provided in the demo. At least with the DMA transport one more thing needs to be considered. There is a very simple mechanism to avoid overruns in the UART transmit DMA. However, that will cost you a lot of time and requires the operating system to be started already. So I changed this also.

Best Regards
Markus