I have some short questions regarding the m4 heap and stack size. First of all we had already to move to the OCRAM linker script as our elf file got quite big. Now I wondered why the heap and stack size are the same for the tcm and ocram memory. So my questions are
Why is the stack / heap size just 1kb also in the OCRAM memory?
Would it do any harm to increase the heap size in the linker script (as long there is enough memory in the specified regions)?
Could one just use the tcm m_data memory region for the heap? Something that speaks against that (besides manually hacking linker files)?
Additional question regarding the FreeRTOS
In the provided examples sometimes the value of the heap is as following.
#define configTOTAL_HEAP_SIZE ((size_t)(20 * 1024))
Am I right in the assumption that these is inconsistent with the linker files and should at the moment be 1 * 1024?
FreeRTOS uses its own memory allocator. By default, the FreeRTOS heap is actually part of the uninitialised data section (bss). The heap is an array defined in rtos/FreeRTOS/Source/portable/MemMang/heap_2.c which is then managed by FreeRTOS. It is not a very nice solution in my opinion, but it is portable and seems to work.
The heap defined in the linker file is the heap used by the C library (which provides malloc/free). The linker file exports the symbol _end (through PROVIDE(end = .);) which is picked up by the sbrk syscall of the C library (see https://sourceware.org/newlib/libc.html#Stubs).
Toradex BSP is based on NXPs BSP. I am not sure why NXP chose to only reserve 1KiB for the libc heap, I assume because there was no need for more than that… Adjustment of libc heap and FreeRTOS heap is certainly something you might need to adjust depending on your requirement.
It should be possible to use the C library heap in FreeRTOS as well by using heap_3.c implementation in CMakeLists.txt. See also FreeRTOS Memory Management.
