Why malloc() returns null, and how much needed or left for the heap on a STM32F407?

Question

I just found out that my decoder library fails to initialize as malloc() fails to allocate memory and returns to the caller with "NULL".

I tried many possible scenarios, with or without casting and referred to a lot of other threads about malloc(), but nothing has worked, until I changed the heap size to 0x00001400, which has apparently solved the problem.

Now, the question is, how can I tell how much heap needed, or left for the program? The datasheet says my MCU has: "Up to 192+4 Kbytes of SRAM including 64-Kbyte of CCM (core coupled memory) data RAM" Could someone explain to me what that means? Changing that to 0x00002000 (8192 bytes) would lead to dozens of the following error:

Error: L6406E: No space in execution regions with .ANY selector

Isn't 8KB of RAM is fraction of fraction of what the device has? Why I can't add more to the heap beyond the 0x00001800?

The program size reported by Keil after compilation is:

Program Size: Code=103648 RO-data=45832 RW-data=580 ZI-data=129340

Answer 1

The error Error: L6406E, is because no enough RAM on your target to support in linker file, there is no magic way to get more RAM, both stack and heap are using RAM memory, But in you case it seems to have more than enough memory but compiler is not aware of same.

My suggestion is to use linker response files with the Keil µVision IDE and update required memory section according to the use..

The linker command (or response) file contains only linker directives. The .OBJ files and .LIB files that are to be linked are not listed in the command file. These are obtained by µVision automatically from your project file.

The best way to start using a linker command file is to have µVision create one for you automatically and then begin making the necessary changes.

To generate a Command File from µVision...

Go to the Project menu and select the Options for Target item.

Click on the L166 Misc or L51 Misc tab to open the miscellaneous linker options.

Check the use linker control file checkbox.

Click on the Create... button. This creates a linker control file.

Click on the Edit... button. This opens the linker control file for editing.

Edit the command file to include the directives you need.

When you create a linker command file, the file created includes the directives you currently have selected.

Regarding malloc() issue you are facing,

The sizes of heap required is based on how much memory required in a application, especially the memory required dynamic memory allocation using malloc and calloc. please note that some of the C library like "printf" functions are also using dynamic memory allocation under the hood.

If you are using the keil IDE for compiling your source code then you can increase the heap size by modifying the startup file.

;******************************************************************************
;
; <o> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
;
;******************************************************************************
Heap    EQU     0x00000000
;******************************************************************************
;
; Allocate space for the heap.
;
;******************************************************************************
        AREA    HEAP, NOINIT, READWRITE, ALIGN=3
__heap_base
HeapMem
        SPACE   Heap
__heap_limit
;******************************************************************************

if you are using the make enveromennt to build the applicatation then simpely change the HEAP sizse in liner file.

Details regarding same you can get directly from Keil official website, Please check following links,

https://www.keil.com/pack/doc/mw/General/html/mw_using_stack_and_heap.html

http://www.keil.com/forum/11132/heap-size-bss-section/

http://www.keil.com/forum/14201/

BR Jerry James.

Answer 2

Now, the question is, how can I tell how much heap needed, or left for the program?

That is two separate questions.

The amount of heap needed is generally non-deterministic (one reason for avoiding dynamic memory allocation in most cases in embedded systems with very limited memory) - it depends entirely on the behaviour of your program, and if your program has a memory leak bug, even knowledge of the intended behaviour won't help you.

However, any memory not allocated statically by your application can generally be allocated to the heap, otherwise it will remain unused by the C runtime in any case. In other toolchains, it is common for the linker script to automatically allocate all unused memory to the heap, so that it is as large as possible, but the default script and start-up code generated by Keil's ARM MDK does not do that; and if you make it as large as possible, then modify the code you may have to adjust the allocation each time - so it is easiest during development at least to leave a small margin for additional static data.

The datasheet says my MCU has: "Up to 192+4 Kbytes of SRAM including 64-Kbyte of CCM (core coupled memory) data RAM" Could someone explain to me what that means?

Another problem is that the ARM MDK C library's malloc() implementation requires a contiguous heap and does not support the addition of arbitrary memory blocks (as far as I have been able to determine in any case), so the 64Kb CCM block cannot be used as heap memory unless the entire heap is allocated there. The memory is in fact segmented as follows:

SRAM1    112 kb
SRAM2     16 kb
CCM       64 kb
BKUPSRAM   4 kb

SRAM 1/2 are contiguous but on separate buses (which can be exploited to support DMA operations without introducing wait-states for example).

The CCM mmeory cannot be used for DMA or bit-banding, and the default ARM-MDK generated linker script does not map it at all, so to utilise it you must use a custom linker script, and then ensure that any DMA or bit-banded data are explicitly located in one of the other regions. If your heap need not be more than 64kb you could locate it there but to do that needs a modification of the start-up assembler code that allocates the heap.

The 4Kb backup SRAM is accessed as a peripheral and is mapped in the peripheral register space.

With respect to determining how much heap remains at run-time, the ARM library provides a somewhat cumbersome __heapstats function. Unfortunately it does not simply return the available freespace (it is not quite as simple as that because heap free space is not on its own particularly useful since block fragmentation can least to allocation failure even if cumulatively there is sufficient memory). __heapstats requires a pointer to an fprintf()-like function to output formatted text information on heap state. For example:

void heapinfo()
{
    typedef int (*__heapprt)(void *, char const *, ...);
    __heapstats( (__heapprt)fprintf, stdout ) ;
}

Then you might write:

mem = malloc( some_space ) ;
if( mem == NULL )
{
    heapinfo() ;
    for(;;) ; // wait for watchdog or debugger attach
}

// memory allocated successfully

Given:

Program Size: Code=103648 RO-data=45832 RW-data=580 ZI-data=129340

You have used 129920 of the available 131652 bytes, so could in theory add 1152 bytes to the heap, but you would have to keep changing this as the ammount of static data changed as you modified your code. Part of the ZI (zero initialised) data is your heap allocation, everything else is your application stack and static data with no explicit initialiser. The full link map generated by the linker will show what is allocated statically.

It may be possible to increase heap size by reducing stack allocation. The ARM linker can generate stack usage analysis in the link map (as described here) to help "right-size" your stack. If you have excessive stack allocation, this may help. However stack-overflow errors are even more difficult to detect and debug than memory allocation failure and call by function-pointer and interrupt processing will confound such analysis, so leave a safety margin.

It would perhaps be better to use a customised linker script and modify the heap location in the start-up code to locate the heap in the otherwise unused CCM segment (and be sure you do not use dynamic memory for either DMA or bit-banding). You can then safely create a 64Kb heap assuming you locate nothing else there.