Is it good idea to define RTC SRAM section in linker script?

[kurta999]

I think it would be the easyest way to work with RTC's SRAM. In this case I just need to define the section in code where to put my variables. I would like to see someone's opinion who is more experience with STM's than me.

[AvaTar]

It is probably useful to specify the MCU type or family you work with, and the Toolchain/IDE.

Many toolchain use to pick a linker script file from a "repository" when you create the project, and put it in the project folder.

It is reasonable to modify it according to your needs. Some specialties like custom bootloaders even require you to modify it.

Just make sure you work on your project copy.

And second, think of what the linker can achieve, and what it can't.

You cannot put persistent data (constants) into volatile memory via the linker.

Like with external SRAM, you might need to extend the startup code, to initialize such sections properly.

[kurta999]

I use Atolic with STM32L443/L433. I already used linker script for bootloader so I have a minimal knowledge about it. Now I'm just curious what others think about my idea of "defining"' RTC Backup SRAM in linker script for easyer programming, like putting two uint64_t easy to that place by just defining it's location with attribute in GCC. Other things like init values are done at code startup.

(BKP sram would be used for storing motohours which is saved only in every 24/48 hour to flash, this solution improves flash life - motohours can't be in ram because if the module shuts down for some reason, values between two flash saves would lost. )

[AvaTar]

> Now I'm just curious what others think about my idea of "defining"' RTC Backup SRAM in linker script for easyer programming, like putting two uint64_t easy to that place by just defining it's location with attribute in GCC

This is highly toolchain-specific, and I'm not a Atollic user.

The usual way is to define a section for the linker (in the linker script, in your case), and refer to this section at variable definition, either with a # pragma or __attribute.

I suggest to check the Atollic tutorial as well. The Atollic compiler is based on gcc, so probably something like __attribute (section()).

[kurta999]

Thanks for your review, I did it, works perfectly. I was an idiot before and didn't come up with the linker script idea, I made a parser which load everything from backup sram byte-to-byte to predefined structures & vice versa for saving.

I just right now found this article and tried, it works! Might be handy for somebody.

http://blog.atollic.com/using-gnu-gcc-on-arm-cortex-devices-placing-code-and-data-on-special-memory-addresses-using-the-gnu-ld-linker

[kurta999]

This soulution does it's job, but I have a problem. When I add RTC_SRAM section to linker script, after compilation, it will appear in the end of .hex file. This is a problem for our testers when they reprogram the chip, ST-Link throwns them error that "Invalid memory" cause RTC_SRAM (which is invalid flash memory section) is defined in hex file.

TL;DR:

Could somebody help me how to define linker sction to NOT appear in .hex file? I haven't found any helpful information in google.

[waclawek.jan]

Use NOLOAD as output section type.

https://sourceware.org/binutils/docs/ld/Output-Section-Type.html#Output-Section-Type

You could also strip that output section when generating the hex file using objcopy, but I'm not sure how much control you might have over this process in the eclipsoids such as atollic.

JW

[Pavel A.]

No, this is not a good idea, exactly because of the complications.

Instead just define your battery backed RAM data as a struct and access it thru a pointer.

Simple, portable. With the thumb instruction set, compiler will access this memory thru a pointer anyway.

-- pa