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.

AvaTar · ‎2017-09-05

Posted on September 05, 2017 at 07:58

What do you mean with timing requirements?

As you already noticed, erase/program stalls code execution from Flash. This could cause trouble with concurrent real-time operations.

Seems this is not the case your project.

I will need to update the value of a variable every five days (in the worst case scenario) in a lifetime of five years.

...

Normally the device should work at 35°C at most.

In this case, you would hardly ever have to deal with wear-out.

I know of other devices that save every few seconds, and allow ambient temperatures up to +70° - just for comparison.

Using the internal Flash seems a viable way for you.

However, I never tried a F09x, nor Cube/HAL.

Marco S · ‎2017-09-05

Posted on September 05, 2017 at 10:07

Hello Bruno. Thanks, I had already read this document before. In my HAL library there are not files

`

eeprom.h

`

or

`

eeprom.c

`

; what I have as headers are

`

stm32f0xx_hal_flash.h

`

and `stm32f0xx_hal_flash_ex.h

` with their respective `*.c` files. Could you please show me where to download the programs described in the example of AN4061 and if de `eeprom.h` and `eeprom.c` files have any equivalence with `

stm32f0xx_hal_flash.h

`

and `

stm32f0xx_hal_flash_ex.h

`

?

Thanks.

Jeroen3 · ‎2017-09-05

Posted on September 05, 2017 at 10:18

You need to login to your ST account, then at the bottom of the page for AN4061 (STSW-STM32117) there is a 'get software' button.

https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries-expansions/stsw-stm32117.html

But here is a non-login mirror:

https://dl.dropbox.com/s/405gtzqb9ppe9ae/en.stm32f0_eeprom_emulation.zip

Danish1 · ‎2017-09-05

Posted on September 05, 2017 at 10:19

I only know what I have to do to tell my Integrated Debugging Environment (IDE) not to load the variable. I think this translates to (NOLOAD) in the *.ld file. Inside SECTIONS I see:

__persistent_load_start__ = ALIGN(__DATA_SRAM_segment_start__ , 4);

.persistent ALIGN(__DATA_SRAM_segment_start__ , 4) (NOLOAD) : AT(ALIGN(__DATA_SRAM_segment_start__ , 4))

{

__persistent_start__ = .;

*(.persistent .persistent.*)

}

__persistent_end__ = __persistent_start__ + SIZEOF(.persistent);

__persistent_size__ = SIZEOF(.persistent);

__persistent_load_end__ = __persistent_end__;

. = ASSERT(__persistent_start__ == __persistent_end__ || (__persistent_end__ >= __DATA_SRAM_segment_start__ && __persistent_end__ <= __DATA_SRAM_segment_end__) , 'error: .persistent is too large to fit in DATA_SRAM memory segment');

- Danish

Marco S · ‎2017-09-05

Posted on September 05, 2017 at 10:37

Thanks Danish. I have try your suggestion without modifying the *.ld file (I declared a variable as `int preservedVariable __attribute__((section('.persistent')));

`). This works for keeping the variable's value every time I reset the board, but if I cut the power supply the last variable's value is lost. When you have tested this solution is the variable's value kept even if the board is powered off?

Danish1 · ‎2017-09-05

Posted on September 05, 2017 at 10:55

Marco S wrote:

Thanks Danish. I have try your suggestion without modifying the *.ld file (I declared a variable as `int preservedVariable __attribute__((section('.persistent')));

`). This works for keeping the variable's value every time I reset the board, but if I cut the power supply the last variable's value is lost. When you have tested this solution is the variable's value kept even if the board is powered off?

I said in my initial comment, '

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'.

It does not survive having the board powered off. (Sorry to be a pedant but I was explicitly answering the question as to how to make the variable keep its value over reset. This approach cannot survive loss-of-power and I thought I had made that clear.)

Regards,

Danish

Eugene Solo · ‎2017-09-07

Posted on September 07, 2017 at 10:28

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.

Eugene Solo · ‎2017-09-07

Posted on September 07, 2017 at 10:30

i guess it works only if startup code somehow managing those sections, because its very non-standard approach.

Jeroen3 · ‎2017-09-07

Posted on September 07, 2017 at 11:29

EEPROM is the same as flash, it has the same disadvantages, except smaller erase blocks.

You can use two flash pages for simple non volatile storage, eeprom isn't much better for that purpose.

Eugene Solo · ‎2017-09-07

Posted on September 07, 2017 at 11:36

EEPROM generally have more endurance, 100k+ erase cycles or more.

And I know embedded MCUs with byte-wide EEPROM blocks, you dont need to erase *block* to write new value, all you need is to write value. Dedicated storage is more flexible solution anyway.