Otdfbt

I'm working on STM32F303VC. How does the heap allocation work?

When I declare the arrays outside main() it allocates them on the heap - SRAM - 0x2000000 and forth in this MCU. But what determines the size of the heap? (And hence its overflow.)

There are two options:

1. 
   

   In the 'startup_stm32f30x.s' file I see that:

   
   
   

   Heap_Size EQU 0x00000200 // Which is only 1K!
   

   
   
   

   [See here: [http://www.keil.com/support/man/docs/armlib/armlib_chr1358938939461.htm. Anyway, I just used the default file from STM's library]

   
   



2. But on the target configurations options, the R/W memory area is declared to be a size of 0x8000 (which is 32K).

So I checked this in the debugger:

uint16_t _xValH[5000];
uint16_t _xValL[5000];
uint16_t _xVal[5000];
//3*5000*2 bytes each = 30 kilobytes

int main(void) 

 _xValH[4999] = 0x4;
 _xValL[4999] = 0x5;
 _xVal[4999] = 0x6;

This didn't throw an exception - which means that it is the second option of the above. But furthermore, even if I go above the 32K - say:

uint16_t _xValH[6000];
uint16_t _xValL[6000];
uint16_t _xVal[6000];
//3*6000*2 bytes each = 36 kilobytes

int main(void) 

 _xValH[5999] = 0x4;
 _xValL[5999] = 0x5;
 _xVal[5999] = 0x6;

It's still working! The only time it throws me to exception is when I surpass the 40K - which is the limit of the SRAM (0x20009FFF).

So, what is the meaning of the A line code? And the meaning of the size I enter in B?

You misunderstand what the heap is.

The heap is the area where malloc gives you blocks of RAM dynamically at run-time.

Your globally scoped, statically allocated variables & arrays are not 'on the heap'.

If you're not using malloc or any of its variants in your program, you can quite safely set the heap size to 0.

Those are global variables. Which generally are not allocated on either stack or heap. Exactly where they are is a longer discussion.

Your heap space is for 'globally accessible' variables created during run time. Which is different to global variables, which are allocated before your main() function is entered. Heap space variables can be allocated, de-allocated, reallocated and resized. A global variable you're generally stuck with for the entire program execution.

Your stack space is for local variables. Anything put on it by a function will be removed when the function returns.

While some implementations may put some global variables at the base of the stack, it certainly isn't a rule.

Consider:

uint16_t _xValH[5000];
uint16_t _xValL[5000];
uint16_t _xVal[5000]; 
//3*5000*2 bytes each = 30Kbytes

int main(void) {

These are global variable declarations. These declarations reserve permanent static space in RAM. The heap is for dynamic allocations in memory.

The Standard does not require freestanding implementations to provide any sort of heap. In some cases, they will pre-allocate a certain amount of space for use by the malloc() family of functions, with such space being essentially wasted if no such functions are ever used. In other cases, the compiler will reserve a certain amount of RAM for the stack and then make available to malloc() all storage that isn't and won't be used for any other purpose. In still other cases, an implementation won't provide malloc() but will provide the starting and ending address of a range of storage that the implementation has been told the hardware has, but which the implementation itself has no use for; a user application may then subdivide this range of addresses via whatever means it sees fit.

In many cases, the latter approach is the best, because user-written allocation functions can offer finer control over allocations and fallback logic than malloc(). For example, it may be useful to determine, before performing a bunch of allocations, whether all can be guaranteed to succeed (eliminating the need to gracefully recover from an allocation failure in the middle of a task). While malloc() provides no such flexibility, user-written allocation functions can.

I hope this should clear things up. It examples the different method of memory allocation in standard C.

#include <stdint.h>
#include <stdlib.h>
#include <stm32f30x.h>

uint32_t static_allocation;

int main(void)
 uint32_t stack_allocation;
 static uint32_t private_static_allocation; 
 uint32_t *heap_allocation;

 heap_allocation = malloc(4);

 static_allocation = 0x11111111;
 stack_allocation = 0x22222222;
 private_static_allocation = 0x33333333;
 *heap_allocation = 0x44444444;

 while(1)
 // Stop simulation here
 __BKPT(0);
 // remove not referenced warnings
 (void)static_allocation;
 (void)stack_allocation;
 (void)private_static_allocation;
 (void)heap_allocation;
 

 free(heap_allocation);

A quick glimpse at symbol table the ARM Linker generously created shows:

private_static_allocation 0x20000004 Data 4 main.o(.data)
static_allocation 0x20000000 Data 4 main.o(.data)

Which means the linker knows, at compile time, where these variables will live.

Including the following objects in memory map:

0x20000010 0x00000200 Zero RW 2 HEAP startup_stm32f30x.o
0x20000210 0x00000400 Zero RW 1 STACK startup_stm32f30x.o

And to check it really works like this, simulation debugger shows:

Notice stack_allocation isn't on the actual stack yet, but in a register. This is due to the small amount of variables in this example. Even with -O0 the compiler optimizes stack variables.

Also notice the place of 0x11.., 0x22.. with 0x44.. being inside the heap object.

But no other objects are in here. This means that you can safely reduce heap to 0 if you do not use malloc. Some library functions do implicitly.

Both heap and stack overflow are not warned about during compilation since they are runtime errors.

Relevant documentations: __use_no_heap.