How to save a variable in non-volatile memory?

[Marco S]

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.

[Tesla DeLorean]

Posted on September 08, 2017 at 21:54

Basically journalling.

I'd strongly advise against using EEPROM emulation, better to understand the medium you're writing too and adapt to that, than apply a paradigm that isn't appropriate and be surprised when it combines the flaws of both.

[Tesla DeLorean]

Posted on September 08, 2017 at 22:02

The Linker Script (Scatter File) is used to describe areas of memory the linker can use, with EEPROM Emulation you want to carve a hole spanning multiple whole/small FLASH sectors/blocks so the linker places code everywhere but these locations. I'm sure there are ways of using arrays with AT directives, but I find that to be a bit of a kludge, the linker is the best place to manage 'Keep Out' areas.

[Martin HUBIK]

Posted on September 11, 2017 at 11:11

1) It is true that execution is stalled on single bank devices, however STM32L0 category 5 devices feature dual-bank flash. This feature allows read-while-write which means that the code can be exectud from one bank without stalling the execution, while the other bank (Flash or EEPROM) is being programmed.

2) The errase granuality for EEPROM is indeed 32bits, the write granulity is 8/16/32 bits.

[AvaTar]

Posted on September 11, 2017 at 14:07

Small chance of this but I assure you that it will happen sometimes.

This matches with my experiences. And, assuming a commercial project, those will be field returns from angered customers...

You might contemplate you requirements and project suppositions again.

I have been through a design that detected mains-off events, and performed a full parameter save from the remaining charge of it's power supply main cap (an electrolytic cap).

It worked - most of the times ...

You need to find the proper costs/safety tradeoff for your project.

[Dan Mackie]

Posted on September 11, 2017 at 14:39

Most of the time?? I'd hope we can do better than that. Seems to me that in a battery/solar system, allowing saves of critical parameters to happen only when voltage is above a safety level measured by the a/d should guarantee operations except for human intervention cases, and it should be easy to manage that with on board leds to indicate 'power off allowed' or not, and suitable 'pending save/power off not allowed' warning light patterns. Unfriendly human intervention is enough to kill most any system, depending on the level of animosity and education, so there is usually not much point planning for that. Comments??

Sent from my Samsung device

[AvaTar]

Posted on September 11, 2017 at 14:52

That depends on the device and it's 'HMI'.

The device I spoke about had only a serial communication line and the 'mains plug'.

Persistence of certain parameters was/is a requirements of the communication standard the device was supposed to fulfill.

And the (partially) neglected parameters were ambient temperature and aging, which affected cap charge - more then foreseen.

Unfriendly human intervention is enough to kill most any system, depending on the level of animosity and education, so there is usually not much point planning for that.

Safety-related requirements (SIL) do not fully agree with this statement.

But I assume such requirements do not apply here.