2021-03-06 06:04 PM
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
2021-03-06 10:29 PM
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
2021-03-07 08:37 AM
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.
2021-03-07 02:35 PM
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:
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
2021-03-07 11:43 PM
> 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
2021-03-09 02:11 PM
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
2021-03-09 10:33 PM
Hi Rob,
right. You can check or change it in Project Propertieshth
KnarfB