How is virtual stack/heap size calculated given physical RAM constraints

Question

I am working on a particular embedded device from Nordic. The datasheet states 256kB of flash, with 16kB of RAM, on a 32-bit Cortex M0. With that said, my main question is about the stack/heap size given the physical RAM constraints. I found documentation here regarding RAM/ROM management and their associated usages, however it's still unclear how the stack size is calculated. For example, I found an assembly configuration(arm_startup.s) that sets the max stack/heap size to 2048 bytes.

                IF :DEF: __STACK_SIZE
Stack_Size      EQU     __STACK_SIZE
                ELSE
Stack_Size      EQU     2048
                ENDIF

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp

                IF :DEF: __HEAP_SIZE
Heap_Size       EQU     __HEAP_SIZE
                ELSE
Heap_Size       EQU     2048
                ENDIF

                AREA    HEAP, NOINIT, READWRITE, ALIGN=3
__heap_base
Heap_Mem        SPACE   Heap_Size
__heap_limit

                PRESERVE8
                THUMB

As a test in main, I purposely set void *x = malloc(2064) which caused a stack overflow to prove 2048 bytes is being honored. My question is, if you can only have 16kB of RAM, how can you allocated 2048 bytes to both the stack and heap. After searching around a bit I ended up in the Cortex M0 documentation. I could not find any such constraint, but then again I may be looking at this from the wrong angle. Given the assembly snippet above, it would seem somewhere, either in hardware, or software, there is a total virtual RAM size of 4096, split into two for the stack and heap.

Where's the hidden link to the programming languages C and C++? — IInspectable, Aug 25 '16 at 13:25
"I purposely set void *x = malloc(2064) which caused a stack overflow to prove 2048kB is being honored" Eeeh? Doesn't that rather cause a "heap overflow", meaning that malloc fails and returns NULL? That being said, the heap is usually not used in Cortex M0 systems at all, unless there's a confused PC programmer writing the code. — Lundin, Aug 25 '16 at 13:33
Generally, you seem a bit confused about the various memory areas of a microcontroller. Please [read this](http://electronics.stackexchange.com/a/237759/6102). — Lundin, Aug 25 '16 at 13:38
@Lundin can you explain a bit more. I have also read that in general the heap is not used on this Cortex M0. Is it because normally this processor is used in embedded devices in which case you wouldn't want to manage the memory yourself? — RChapps, Aug 25 '16 at 13:39
So what's the question here exactly? 16384 bytes (16k) > 4096 bytes. How is this a problem? — Ross, Aug 25 '16 at 13:40
How do you imagine allocating 1/4 of your available RAM for heap and stack to be a problem? Sure, the exact numbers are a fairly arbitrary choice, but it leaves plenty of room for static data (which is predominantly what most microcontroller code will be using). — Notlikethat, Aug 25 '16 at 13:40
[Here](http://electronics.stackexchange.com/questions/171257/realloc-wasting-lots-of-space-in-my-mcu/171581#171581) is an explanation why the heap doesn't even make sense to use in most embedded systems. — Lundin, Aug 25 '16 at 13:42
@Lundin those links were extremely useful. I am now realizing the flaws in this question. The one outstanding question I still have is that assembly file. What makes 2048 unique? Is this truly just an arbitrary number of bytes? In your post you mention "use every single byte of RAM not used by your program for the stack". Based on that, I should determine the application size from the memory map, and allocate the remaining bytes as needed. — RChapps, Aug 25 '16 at 14:04
@RChapps 2048 bytes = 2kb. Probably taken out of the blue, but it is a fairly normal stack size. The program will likely not use more than a 4th or so of those 2k. Unless you have advanced needs, you can probably leave the default configuration as it is. Maybe remove the heap to give more room to static data. Usually there's some manner of linker configuration file where you can set the memory sizes explicitly (could be called "linkerscript" or some file with extension *.ld, *.lcf, *.prm etc etc, depends on tool chain. I don't remember what Keil calls it.). — Lundin, Aug 25 '16 at 14:20
I am unclear as to why you think there is anything mysterious about allocating 4kb of heap and stack on a 16kb part!? Cortex-M0 has no MMU and therefore does not support virtual memory at all. — Clifford, Aug 25 '16 at 22:02
Simple solution: on such devices don't use `malloc` & friends at all! Use static data or a pool of equal blocks of the required size. — too honest for this site, Aug 25 '16 at 23:06

score 0 · Answer 1 · answered Aug 25 '16 at 18:07

Is there some programming class going on why are we all of the sudden getting hit with the same or related questions?

If you have 16KB of ram then all of your read/write information has to fit yes? If you dont set those defines then that code is producing 2K of stack and 2K of heap so 4K. 4K is less than 16K so you have 12K left for .bss and .data.

Heap makes no sense on a microcontroller normally sure you might port some as written library the mallocs and you just fake that (but you do have to "allocate" basically define how much to use and then implement a simple malloc). But other than say borrowing code written for a higher level platform you dont want to be using malloc.

"allocating" stack doesnt make a lot of sense either as how are you managing that are you telling the compiler to check against some number before every push? and if so then it is compiler dependent and you have to feed the compiler what it needs as well as deal with the excess code that produces and consumes out of your limited resources as well as burns time out of your limited bandwidth. Do your system engineering instead and not have to do it runtime.

The cortex-m has nothing to do with this nor does anything hardware related at all. 2K + 2K < 16K. Just grade school math.

How is virtual stack/heap size calculated given physical RAM constraints

1 Answers1