Available memory - Am I understanding this correctly ?

Kernel
1

lactose99 wrote on Sunday, August 31, 2014:

Hello.
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.

Some info:
-using RX600 CPU
-using heap3.c
-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 ?

void outOfMemoryCheck()
{
	// address of this var used to find bottom of stack
    int32_t testStackVar = 0; 
	uint8_t *pHeap = NULL;
#define TEST_ALLOCATION_SIZE 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 
		while(1);
	}	


	free(pHeap);
}

Thanks.

2

richard_damon wrote on Monday, September 01, 2014:

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.

3

lactose99 wrote on Monday, September 01, 2014:

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 ?

4

richard_damon wrote on Monday, September 01, 2014:

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.