micro-ROS
Dual ucHeap memory regions.
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!
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
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!
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