cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE: How to allocate memory to different H7 Memory blocks

Garnett.Robert
Senior III

I wish to take advantage of the various memory blocks of the H7 processors:

   Put the stack and heap in the DTCMRAM

   Put DMA buffers in various blocks etc.

In Keil uVision I use scatter (.sct) files which makes it easy.

I cannot find a way of doing it in STM32CubeIDE.

I searched the forum and found I could maybe? do it by manually editing the linker script:

xx_RAM.ld

However this is an auto generated file so any changes I make will at some point be overwritten.

I don't find this a very practical and secure method of allocating memory blocks.

Is there some other way from within STM32CubeIDE?

If not how do I get over the auto-generation issue?

Has anyone come up with a reliable way of allocating memory that works around the problems?

Best regards

Rob

6 REPLIES 6
KnarfB
Principal III

The .ld file is the correct place for doing that. Examples are in the "STM32CubeIDE user guide". The .ld file is not completely re-generated. Your custom added memory sections will be respected. However, I didn't find an official statement declaring what and when will be changed and what not. E.g. Minimum Stack and Heap sizes from .ioc Configuration *will* be copied to .ld file, which makes sense anyway.

To be on the safe(st) side you may copy the .ld file to a custom file name and specify that in the project properties > build > linker settings.

hth

KnarfB

Probably not an answer/method that will make everyone happy. Realistically if the linker script method is not desirable, you'd likely need to build you own allocators, which service multiple memory pools as appropriate for distance from the core, or peripheral/dma access desired.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hi Knarf,

Thanks for that. I played around with the .ld and found that it doesn't get overwritten.

My project is based on the Discovery board STM32H7B3I-DK which I generated using TouchGfx. I have two linker script files:

  • STM32H7B3LIHXQ_FLASH.ld
  • STM32H7B3LIHXQ_RAM.ld

Why are there two files?

Which one should I edit, or should I edit both?

I wish to use the battery backed domain ram to save initialisation data, but I have been unable to find an example of how to do this. Of course the battery backed ram shouldn't be initialized at start-up. Can you point me to an example or explain how to do this? I am using HAL drivers.

Best regards

Rob

> Why are there two files?

Look at the memory areas: there is no FLASH defined in the RAM.ld, but the code (.text), read-only data (.rodata) and interrupt vectors (.isr_vector) all go to RAM_EXEC. That's the main difference. For a stand-alone system you probably need the flash for persistent storage.

> wish to use the battery backed domain ram to save initialisation data, but I have been unable to find an example of how to do this.

> Of course the battery backed ram shouldn't be initialized at start-up.

The .ld file is mainly a definition of memory areas. The startup code knows about certain symbols used in .ld file like _sbss, _sdata and more and uses these to know what to initialize (copy from flash to ram or zeroing out). If you define your own area of RAM, it will not be touched by system code. You may use it as shown in the above "user guide".

Haven't specifically worked with backup RAM on H7 though.

hth

KnarfB

Hi Knarf,

I did look at the two .ld files and I saw they were different, so when I push the "build" button which one is the build using? My guess is it is using the xxflash.ld as the program loads and runs.

Best regards

Rob

Hi Rob,

right. You can check or change it in Project Properties0693W000008wTkzQAE.pnghth

KnarfB