I have been seeing some strange stuff in my software (debugger stepping wrong, variables passed to a function that land with the wrong value...). I wrote a quick function to see how much free memory is left, and it indicates I am out of memory.
-using RX600 CPU
-optimization = 0
My outOfMemory function assumes stack is at the top moving down, and heap is on the bottom moving up. Experimentally, this matches my observations. So is measuring from the bottom of the stack to the top of the heap a valid way of determining free memory ?
// address of this var used to find bottom of stack
int32t testStackVar = 0;
uint8t *pHeap = NULL;
define TESTALLOCATIONSIZE 8
// determine the top of the heap
pHeap = malloc(TEST_ALLOCATION_SIZE);
// available_memory is bottom_of_stack - top_of_heap
// stack bottom should never be below heap top
if((NULL == pHeap) || ((int32_t) pHeap > (int32_t) &testStackVar))
// we are out of memory, loop here
No, this is not true in FreeRTOS. Each tasks stack will be allocated from within the FreeRTOS heap (which with heap3.c is the C heap).
The primary issue is that you no longer have THE stack, but each task has their own stack.
Wow, thanks for the quick response. My apologies, I did not qualify that I am calling this outOfMemoryCheck function from a comm sci TX interrupt. In that case, I believe I am looking at the system stack.
In that case, I can assume that stack bottom should never be below heap top. Correct ?
It depend on the port, some will use the starting stack for the interrupt routines, some don't.
Best is to check your linker map and the addresses that are being reported.