a) where's the heap
b) where's the stack
c) what's sbrk
I'm using an open-source tool-chain (codesourcery lite).
a) The heap is the region of RAM on your stellaris that isn't being using by your program.
So for example, on the LM3S6965 - 64k SRAM starts @2000 0000 and ends @ 2001 0000 (-1).
If you look in your map file, you'll find that you are only using say 2000 0000 to
2000 4000. This means that the RAM from 2000 4000 to 2001 0000 is unused (the heap) -
free for dynamic memory allocation. The heap grows upwards (increasing address).
You need to modify your linker script standalone.ld as follows :-
(only the last part of bss and the two provides are different from the standard)
This gives us access to the start and end address of the heap - on any Stellaris.
Note that the start address can change each time you rebuild, but we have it.
b) The stack is the region of RAM where the system puts all the function call parameter data & local data.
If you look in your startup.c file, you'll see something like this :-
#define STACK_SIZE 512
static unsigned long pulStack[STACK_SIZE];
void (* const g_pfnVectors)(void) =
(void (*)(void))((unsigned long)pulStack + sizeof(pulStack)), // The initial stack pointer
This is your stack start address and stack size. It's buried in your program's RAM.
You can find the real start address and end address in the map file if you want - but it's not important.
The stack grows downwards (decreasing address).
As long as the STACK_SIZE is big enough for your program, it will not overwrite your other RAM variables just preceeding it.
You could move your stack to the end of the heap and let it grow downwards - to one day meet your heap coming the other way,
but the above solution means that no collision is possible.
c) So, last time you tried to use malloc, it didn't compile because of an error - sbrk missing.
Malloc uses sbrk to get hold of the RAM addresses it will allocate back to you.
Note the use of our new PROVIDEs from the linker script, the memory addresses allocated can only be from our heap,
so there is no overlap with the program RAM. When all of the RAM is used, sbrk will tell malloc and malloc will tell you
- i.e. return NULL
Create a file called syscalls.c :-
Ready to go ...