RAM, Heap, and Stack memory for an STM32 board

Question

I am working on a project that requires at least 500 kB of memory to be used. I have an SDK with this code defining the stack and the heap and it works fine.

Stack_Size      EQU     0x00004000

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


; <h> Heap Configuration
;   <o>  Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>

Heap_Size       EQU     0x00200000

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

However, I am trying to integrate a camera and LCD screen feature into this SDK, and when I do that, the highest values of the stack and heap that will at least bring up the LCD screen are shown below. Any values higher than this and the LCD screen stays black and the application doesn´t appear to run.

Stack_Size      EQU     0x00004000

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


; <h> Heap Configuration
;   <o>  Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>

Heap_Size       EQU     0x00002B50

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

I need the sizes of the stack and heap in the second code sample to match the sizes in the first code sample so that I do not get stuck in a hard fault exception loop due to no memory being available. Why does increasing the heap size make my project worse? Meaning how come it doesn´t even appear to run when I increase the heap size?

I have attached a screenshot of my project options so you can see the configuration of the RAM.

Below is the amount of memory I have. Doesn´t this mean that I have 2 MB of RAM?

8 M x 32-bit SDRAM is connected to SDRAM Bank1 of the STM32F439NIH6 FMC interface.

1 Mbit x 16 SRAM is connected to bank1 NOR/ PSRAM2 of the FMC interface and both 8-bit and 16-bit access is allowed by BLN0 & BLN1 connected to BLE & BHE of SRAM respectively.

Answer 1

Your STM32F4 microcontroller does not physically have 0x200000 (2 MB) of RAM beginning at address 0x20000000. I believe it has only 0x30000 (192 KB). Check the memory map section of the datasheet.

If you tell the linker that there is non-existent memory available, then the linker may try to use that memory and then your program will crash. I suspect for your original program the linker never used the non-existent memory so the program ran successfully. But in your subsequent program the linker is trying to use the non-existent memory and the program is crashing. Look at the map file generated by the linker to see how the various parts of your program have been assigned into memory by the linker. You'll probably find that the first program doesn't use memory beyond 0x20030000 but the second program does.

If you really need 500 KB of memory or more then you're going to have to add an external memory device to your board because the microcontroller does not have that much RAM.

Update: If your board has memory connected to the FMC (flexible memory controller) then that is external or off-chip memory. The external memory is not addressed at 0x20000000 though. It should be located somewhere in the range of 0x60000000 to 0xDFFFFFFF (see the memory map section of the datasheet). Your program will have to configure the FMC appropriately before accessing the external memory. And you should probably tell the linker that the external memory exists by enabling one (or more) of those off-chip memory sections in that options dialog box. You can probably get details and advice about how to enable the off-chip memory from the board designer.

Answer 2

If you tell the linker you part has 2Mb on-chip ROM and 2Mb + 64Kb of on-chip RAM it will believe you, and happily locate code and data accordingly - but don't expect anything useful to happen when you access memory that does not exist!

If you set the memory areas correctly, the linker will fail when you have exceeded the target's capacity. That's a physical limit, the solution is not to lie to the linker - that just generates a runtime error rather than a build error.