Feature Request: "no-init" linker section

[Andrew Neil]

It is a common requirement to have an area of RAM that is not cleared or otherwise initialised by the startup code; eg,

https://community.st.com/t5/stm32cubeide-mcus/how-to-make-keep-ram-value-after-software-reset/m-p/96132

https://community.st.com/t5/stm32cubeide-mcus/how-to-port-no-init-iar-directive-with-to-gcc-compiler-please/m-p/661867

to mention but two.

Currently, this means making manual edits to the linker script - which get overwritten with every 'Generate'. :frowning_face:

So how about adding a "noinit section" option in the Project 'Linker Settings':

 

 

Or making the generated linker script have areas which will not get overwritten - as in the generated 'C' code.

 

(I've tagged this as 'Bug Report' because the forum insists on having a tag, but none of the available tags is relevant! 'Bug Report' seems the least worst.)

[Pavel A.]

> Or making the generated linker script have areas which will not get overwritten

Maybe easier and faster can be to write a KB article about implementing a no-init RAM section. This not necessarily can be a piece of the "main" RAM. Some STM32s have the backup RAM, or several SRAM units that are not referenced in the "standard" link script. These can be used for no-init data as well.

 

[Radosław]

I'm waiting many years to have posibility to define new section and menage them  in MX or IDE.

[Pavel A.]

Manage sections in a GUI? Do you mean, a GUI for GNU ld scripts? This is possible, as an Eclipse add-on.

You can propose this in the common Eclipse CDT forum, even sponsor this idea to show your motivation and support.

A simpler variant can be like the linker option dialogs in Keil MDK and IAR IDE: a couple of input fields, like ROM1, ROM2, RAM1, RAM2... address & size, with "no init" check boxes. These fields generate defined symbols prepended to a common link script with conditional ifdef's. ... and so on.

[Radosław]

Done by many people In many ways,  Compatitors creates this long time ago. 

 

I have my own solution for this :D

 

[Andrew Neil]

---

@Andrew Neil wrote:

Currently, this means making manual edits to the linker script - which get overwritten with every 'Generate'. :frowning_face:

---

Actually, it seems that's not true - 'Generate' does not (necessarily?) overwrite the linker script.

[BarryWhit]

My point is that ST has already (for some families) implemented a GUI for editing memory sections that drives linker script generation - so what Andrew (or your own thread hijacking feature request) is asking for is a natural extension of something that already exists, not a complete rewrite of their flow.