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]

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

}