RAM sections, map file, RAM memory filling

[Davide Michelis]

Posted on May 18, 2018 at 14:54

Good morning,

I am developing an application that uses STM32F3DISCO as board and FreeRTOS as OS. I want to keep some data in the RAM after some Software reset that I do under some conditions so I have used the notation

__attribute__((section('.my_section')))

near the variables I want to preserve. Moreover in the linker script I have added a section just after .data and before .bss

.my_section (NOLOAD):

  {    . = ALIGN(4);    _s_my_section = .;           *(.my_section)    . = ALIGN(4) ;    _e_my_section = .;   } > RAM

Now, the application works correctly and the values are preserved but I want to understand more:

when I do a reset pressing the button I get my values stored  -> OK

when I do a power on reset values are more or less random -> OK

To put a 0 in those locations again I have to upload a program without that section defined...is the SRAM reset to 0 when a new .bin is flashed? Because otherwise I cannot explain this behavior.

Sorry if the question could seem a bit naive.

Greetings,

Davide

#soft-reset #memory-sections #ld-script #linker

[Tesla DeLorean]

Posted on May 18, 2018 at 15:12

The download process usually puts a loader into RAM, and that uses other areas of RAM to perform the FLASH Erase/Write operations.

If you leave persistent data in RAM you might want to consider placing that all within a structure, and then having signatures and checksums so you can verify the integrity of that data, and copy in some new defaults when there is no valid data there.

[Davide Michelis]

Posted on May 18, 2018 at 15:48

Uhm ok thanks, so how can I be sure that I'm going to reset the region I will use to store/update those data across resets? 

[Tesla DeLorean · Accepted solution]

Posted on May 18, 2018 at 16:22

I'd probably lean toward putting this kind of data in the top of RAM, and shrinking the memory described to the linker. Or use the BKPRAM/NVRAM if available. On the F3 the 16KB of CCMRAM might be less vulnerable to use by the tools.

>>Uhm ok thanks, so how can I be sure that I'm going to reset the region I will use to store/update those data across resets? 

Storage structure has a leading signature, and trailing checksum/crc, this will fail a simple integrity check across the power-up scenario.

typedef struct _FOORAMSTRUCT {

uint32_t Sig;

uint32_t Foo;

uint32_t Bar;

uint32_t Crc;

} FOORAMSTRUCT;

FOORAMSRUCT *ramstuff = (FOORAMSRUCT *)0x10000000;

if ((ramstuff->Sig == 0xCAFECAFE) && (Crc32(0xFFFFFFFF, ramstuff, sizeof(FOORAMSTRUCT)) == 0)

{

  // Structure Intact

}

else

{

// Structure Corrupt - copy in new defaults and sign

}

[Davide Michelis]

Posted on May 18, 2018 at 17:10

OK then the idea is:

- when i upload a new program, RAM is used to perform some movement from/to Flash and so if I get a region filled with 0 is just by chance

- solution could be using a known region in the RAM (like you said the top) and then accessing it directly: this is a kind of absolute mapping

Thank you for the suggestion of the structure and integrity check too.

Best regards, Davide

[Tesla DeLorean]

Posted on May 20, 2018 at 22:46

Depending on the tools and implementation the startup code can often zero the statics, heap and stack. The hardware operates at a much more simplistic level, where the RAM content at startup is indeterminate and inconsequential. The reset typically clearing registers and internal states, but not iterating through memory clearing it.

[Davide Michelis]

Posted on May 22, 2018 at 10:28

Ok thank you, I have implemented an additional mechanism to reset those variables before the first cycle begins.

Best regards,

Davide