Changing configTOTAL_HEAP_SIZE

kkelkar wrote on Friday, August 03, 2007:

I am trying to allocate a buffer to write an event log file to. I can do so without issue within the current configTOTAL_HEAP_SIZE size limit. However, when I try to increase my configTOTAL_HEAP_SIZE by even 1000, FreeRTOS seems to stop running.

I am running on a SAM7S256 with 64K of memory and my configTOTAL_HEAP_SIZE is set to 14200. It seems like I should have the RAM to use. Does anyone have any suggestions on what else I need to change or look at to figure out why I cannot increase my heap size?

rtel wrote on Friday, August 03, 2007:

Take a look in your map file, this will tell you how much RAM you have available and where it is being used up.  I would have thought though that you would get a linker error if configTOTAL_HEAP_SIZE was too large.  Do you have the correct linker script for the S256?

Are you allocating the buffer before starting the scheduler or afterwards.  If afterwards then maybe you don’t have enough heap left to create the idle task.  Check whether or not vTaskStartScheduler() is returning (the idle task is created automatically when you start the scheduler).


jcwren wrote on Friday, August 03, 2007:

I don’t know what compiler and library you’re using, but I can tell you this: With GCC and newlib, the sbrk() function in newlib/syscalls.c (which is tailored to your system) performs a check to see if the end of heap pointer is greater than the stack pointer, and if it is, it fails.  This is a very primitive but effective method of determining if the heap and stack will collide.

When running FreeRTOS, the stack is in the static memory area, which is in low memory.  This implicitly means that the stack pointer will appear to be below the end of the heap, and cause sbrk() to fail. 

If you’re not running GCC + newlib, then this may well not be applicable.   I do know I was getting weird behavior with FreeRTOS appearing to lock up, or certain tasks failing (and others still running) until I nailed this down.

In the LPC2148_V130 demo package (which I should be releasing this weekend after a couple more checks), I’ve implemented this fix.


kkelkar wrote on Friday, August 03, 2007:

Sorry - I should have included the fact that I am using IAR in my original post.

That said, after the useful responses, I went back and checked the linker file. I found out that I had started this project based on the IAR SAM7s64 demo and had changed all the board configs and target processor, but not the linker files.

Thanks for the quick and helpful responses.