Skip to main content
Garnett.Robert
Garnett.Robert
Senior III
March 7, 2021
Question

STM32CubeIDE: How to allocate memory to different H7 Memory blocks

  • March 7, 2021
  • 2 replies
  • 5594 views

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

This topic has been closed for replies.

2 replies

KnarfB
KnarfB
Super User
March 7, 2021

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

Garnett.Robert
Garnett.RobertAuthor
Senior III
March 7, 2021

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

KnarfB
KnarfB
Super User
March 8, 2021

> 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

Tesla DeLorean
Tesla DeLorean
Guru
March 7, 2021

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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
Terms & ConditionsAccessibility statement