NRF memory management and FreeRTOS coexistence

You have a few options here:

First, you can set FreeRTOS up so it only uses statically allocated memory, so there is no FreeRTOS heap and you can use the heap defined by your programming environment.

Second, you can define pvPortMalloc() and vPortFree() to use the heap defined by your programming environment.  If you do that then make sure you make it thread safe, as shown here for heap_3.c, which uses the standard C library malloc() and free().

Third, if possible, you can make the native programming environments memory allocation functions call pvPortMalloc() and vPortFree().

All the options so far ensure there is only a single heap.  If you want to maintain separate FreeRTOS heap and native environment heap:

Forth, you can dimension the FreeRTOS heap to be just big enough as needed, and set the native heap size however you would do that normally.  Then allocations made by FreeRTOS (if you don’t allocate everything statically) come from the FreeRTOS heap, and everything else comes form the native environment’s heap.

Thank you for your answer. It is exactly what I did.

I guess I didn't ask the question clearly. The question should be: what is the boundary of NRF heap?

Without NRF_LOG I don't use any heap. So the boundary is __HeapLimit address, which is the same as __bss_end__ because heap size is 0.

But NRF_LOG uses dynamic heap allocation. And it can't be disabled even if I just want a non-deferred log. What API shall I call in order to get the end of the NRF heap?

Thank you for your answer. It is exactly what I did.

I guess I didn't ask the question clearly. The question should be: what is the boundary of NRF heap?

Without NRF_LOG I don't use any heap. So the boundary is __HeapLimit address, which is the same as __bss_end__ because heap size is 0.

But NRF_LOG uses dynamic heap allocation. And it can't be disabled even if I just want a non-deferred log. What API shall I call in order to get the end of the NRF heap?

Never mind, finally, I came up with my own solution.

I created a modified version of nrfx_uart library for blocking UART TX call. The trick is that it has to be thread and TSR safe while the official UART library can achieve.

Of course, I have my own printf.

I wouldn't mind that the output may be "cut in" because of a context switch (caused by an ISR). It is still very readable and much more robust.

nrf_balloc is using pool of statically allocated memory which is not actually Heap to FreeRTOS. I do not see any connection in how nrf_balloc works interfering with FreeRTOS assuming that the linker scripts on memory ranges are set correctly.

Thanks for your response. I double checked. The code is compiled with newlib-nano (--specs=nano.specs). I can see some overwrite after __HeapLimit address. Is there any NRF code called malloc in libc? because I see some overwrite after __HeapLimit address.

If I compile by setting -D__HEAP_SIZE=1024 in both cflags and asm_flags, the code is working fine.

As far as my searching skills goes, I cannot see any of the freertos examples calling malloc and also isee that the macro configUSE_NEWLIB_REENTRANT is disabled in all our examples showing that the examples are expected to work without newlibc. If there is any dependency that unwantedly happened, it should be a bug, but i do not see any such dependency.