How to save a variable in non-volatile memory?

Often changing variables are not recommended to be stored in FLASH.

Writing on-chip FLASH has a significant performance penalty*, and it will wear out relatively quickly.

I limit my use cases for using on-chip flash to configurations and bootloaders only. Both are use cases when the chip is not performing it's critical task.

If you have a variable that you need to keep, I recommend using the backup registers or external EEPROM or FRAM.

Depending on the frequency you want to update the variable with you can decide if the durability of EEPROM is sufficient, else you can use FRAM which will last forever. (10 trillion writes)

*up to 40 millisecond halt for erase, endurance of 'only' 10 kcycles.

You can have a variable keep its value if the microcontroller resets. All you need do is convince the start-up code put in by the compiler not to put a default value in there.

With Rowley Crossworks I put load = 'No' into the section placement file. So I'd declare my variable e.g.

int preservedVariable __attribute__((section('.persistent')));

and have this line in the section-placement file:

<ProgramSection alignment='4' load='No' name='.persistent'/>

I'm not sufficiently-familiar with other development environments to say how you'd do it with them.

Of course the variable is volatile and at power-on-reset or other severe crash the value is junk. You can tell if you're at a power-on-reset by looking at RCC->CSR

Hope this helps,

Danish

Hi Marco,

you may find some interesting things in

http://www.st.com/content/ccc/resource/technical/document/application_note/2e/d4/65/6b/87/dd/40/25/DM00049914.pdf/files/DM00049914.pdf/jcr:content/translations/en.DM00049914.pdf

Regards

Bruno

thats why i dont undedrstand ST's idea about not implementing embedded EEPROM array into stm32 chips - it may be not everyones need, but really useful feature when you need to configure your device somehow, or store some data in persisent storage..

and thats why im forced to use external EEPROM or Flash chips. Serial flash/eeproms are really cheap these days, but they consume some pins and, in some cases, occupied area can be critical issue too. Anyway, embedded or not, dedicated hardware helps to avoid software quirks.

I suggest writing the value(s) at successive locations in a sector.  When you startup scan through to the last one.  That way you should not need to erase very often.  You can adjust the maximum size of flash used so that you stay well below the endurance limit.  If you want to use 'ping-pong' sectors then put a sequence number at the start of the log so you know which one is the newest if you detect both of them active at startup.

Marco - did you get your issue resolved?  I did a file compare with the AN4061 version for the F091,  against what I am using for our Nucleo-F429- found in projects>stm32f429zi-nucleo>applications>eeprom etc, and the files are different, but the principal entry points for reading and writing your own data seem to be the same.  I just implemented ST's eeprom.c in our applications for the F429 this week.  A comment from Clive One was useful in terms of a modification to the .LD file.  I am not using his comment yet, as the application does not seem to load into the target area used by eeprom.c to date.  In any case, read and write, and read at boot time are working so far to implement a 'non-volatile ram' concept.  I deliberately do not preserve all of my data tables, just items that are critical, and since these items are user setpoints, they will rarely change, but I want them preserved across power fails.  Trying to duplicate the full memory of 128K SRAM being preserved with data being changed at machine speeds which we had on Intel/Innovasic architecture before moving to the Nucleo-F429 is not likely until we implement our own board, or ST improves the Nucleo significantly.

mailto:Dan.Mackie@DrSCADA.com

If you do implement saving a critical variable to non-volatile memory, you should also use a checksum,crc or write ones compliment. This way after a power off/on cycle you can detect if the power off occurred during the data write cycle. Small chance of this but I assure you that it will happen sometimes.