How to save a variable in non-volatile memory?

Marco S · ‎2017-09-04

Posted on September 04, 2017 at 09:49

Hello,

I'm using a STM32F091VBTx microcontroller and for the application I'm implementing I need a variable to be constantly updated and it must be stored in a non-volatile memory in order to keep its value even if the microcontroller resets. I've found AN2594 about EEPROM emulation, but the functions described there are not available for the microcontroller I'm using. Should I use the functions provided in the stm32f0xx_hal_flash.c file? If yes, I would like to know if there is a demo software for this or if there is any other method to update values in a non-volatile memory.

Thanks.

#stm32f091vb #variable #non-volatile #memory #eeprom-emulation

Note: this post was migrated and contained many threaded conversations, some content may be missing.

Jeroen3 · ‎2017-09-07

Posted on September 07, 2017 at 11:47

I don't know if that is because the eeprom is electrically different, or because of a wear leveling controller.

Maybe memory mapped SPI flash/eeprom/fram is something ST could consider instead of on-chip eeprom?

Eugene Solo · ‎2017-09-07

Posted on September 07, 2017 at 11:55

i never heard about wear-leveling controllers for EEPROM.

memory-mapped SPI flash exists for higer STM32 chips (QSPI to be correct) and it is not allowing WRITE in this mode, only read: to write something you must switch to indirect mode, write your data and then switch to memory-mapped mode.

Eugene Solo · ‎2017-09-07

Posted on September 07, 2017 at 12:05

dedicated flash memory array with minimal granularity (8 or 32bit wide) would be useful asset. Shame it doesnt exists in STM32 chips

Lorne Vaasjo · ‎2017-09-07

Posted on September 07, 2017 at 14:59

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.

AvaTar · ‎2017-09-07

Posted on September 07, 2017 at 13:48

I would refrain from writing single values to Flash.

Instead collect them, and write all in one block.

Perhaps two blocks in ping-pong mode, that would give you a fall-back dataset just in case.

Dan Mackie · ‎2017-09-07

Posted on September 07, 2017 at 16:01

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

jim23 · ‎2017-09-07

Posted on September 07, 2017 at 17:09

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.

Marco S · ‎2017-09-07

Posted on September 07, 2017 at 17:35

Dan, I haven't solved the issue yet. I used the `eeprom.c` example shown in `en.stm32cubef0\STM32Cube_FW_F0_V1.8.0\Projects\STM32F091RC-Nucleo\Applications\EEPROM\EEPROM_Emulation` which uses HAL library. I'm trying to keep just one variable by using the `eeprom.h` functions to write the value and I lose the information after a reset or after a power off of the board. I'm checking if maybe I'm using wrong addresses. I have not modified the *.ld file.

Dan Mackie · ‎2017-09-07

Posted on September 07, 2017 at 18:32

I am using eeprom.c/.h almost unmodified – I had to add an entry point to load my own address tags for data that I wanted to save. Their idea of three only values, with address tags of 5555, 6666, and 7777 was not quite what suited my interest. Ensure that the target address is within the flash address space, and not occupied by your own code, and see what you get. What are you using for a development system? I am using Raisonance. I wrote a wrapper module to do the calls to EE_WriteVariable and EE_ReadVariable, so I would use the read on boot, and the write otherwise, and keep all the HAL type calls within an interface layer that can be replaced or re-written as porting may require. Note that ReadVariable needs a pointer, and WriteVariable does not. If I can help, let me know.

Dan

Martin HUBIK · ‎2017-09-08

Posted on September 08, 2017 at 09:56

STM32L0 devices have up to 6 KB of EEPROM.