X-CUBE-EEPROM software package fills up emulated EEPROM with zeros on every call to EE_Init()

[B Zikhali]

I am using an STM32L422RB and I have added the X-Cube-EEPROM SW package (version 3.0.0). After intensive use I noticed that the eEEPROM driver is actually writing 64 bits of 0's to my emulated EEPROM space on every device power up or wakeup.

 

On further investigation this is linked to the function EE_Init which calls the function VerifyPagesFullWriteVariable(0U, 0U) and according to the code comments performs a dummy write of 0 to get rid of potential instability of line value 0x0xFFFFFFFF consecutive to a reset during write here.

Why is this done and can this behaviour be avoided as this is effectively wearing out the flash needlessly, my application needs to go in and out of Standby regularly to save power and these writes will create non-negligible Flash wear.

Related to this question.

[vgraglia]

Did you solve this issue? I am facing this with my application on every call to EE_Init() after reset.

[StéphaneM · Accepted solution]

Hello,

This write of zeros in the initialization sequence has been added in order to make the EEPROM emulation driver robust to asynchronous resets and power-downs.

During the validation of the EEPROM emulation software, we noticed that sometimes, if an external asynchronous event (reset or power-down) interrupted a Flash write operation, then this Flash line was no longer writable. Reading that Flash line gave various results including 0xFFFF FFFF FFFF FFFF which did not allow to differentiate a corrupted Flash line from an erased line by performing a simple read operation. The solution to this issue was to systematically write zeros to the first available Flash line after reset.

Note that from a theoretical standpoint, the RM0351 and RM0394 warns that “The contents of the Flash memory are not guaranteed if a device reset occurs during a Flash memory operation.�? If you can guarantee that no external event will interrupt a Flash write operation, then you can simply remove the Step 8 of EE_Init function. This the case for instance if only entering Standby mode (which controlled by the application software) generates a reset and no other external reset is possible in the application.

But , if in practice, you cannot guarantee that an external reset or power down will occur during a Flash write operation, it is better to keep Step 8 of EE_Init in order to make sure the content of the EEPROM remains always valid.

Best regards,

Stéphane

[RMala.2]

Hello @St�phaneM​ 

I understand how data recovery mechanism works and need to write zeros during EE_Init at the end of the emulated EEPROM.

Is it possible to improve EE_Init routine with respect to the flash wearing of the emulated eeprom because of writing zeros on every restart?

Why it is necessary to write zeros even the eeprom variables were not modified from the last restart of the device? For example the EE_Init routine can skip Step 8 if the zeros are already there from the last restart. In this case I think it is not needed to write additional zeros at the end of the emulated eeprom as you can see on the picture above. Because the zeros are already there.

How it sounds to you?

We are facing with the same issue. We are using low flash write endurance MCU.

MCU STM32G070RB has endurance only 1 kcycle.

Thank you and best regards

Roman.

[RMala.2]

Hello @St�phaneM​ 

I have implemented a small routine which checks if there are dummy zeros at the end of the emulated location. And if the dummy zeros are detected it will skip step 8 during EE_Init().

Is it OK to skip step 8 if there are dummy zeros detected as the latest written data in the emulated eeprom? Or am I missing something and this improvement won't be working correctly with regards to the recovery mechanism?

I am looking forward to your answer.

Thank you and Best regards,

Roman.

[Bob S]

What happens when you have this sequence:

• Your system boots and EE_Init() writes dummy zeros (at the end of your data)
• Your code starts a FLASH write cycle to store new data in the emulated EEPROM
• That FLASH write cycle is interrupted by a reset/power failure such that the first FLASH bytes after the dummy zeros from step 1 are corrupted but still read as 0xFFFF FFFF FFFF FFFF as mentioned in the previous ST post
• Your system boots and finds dummy zeros followed by what LOOKS like 0xFFFF and decides to skip writing another block of zeros
• Your system attempts to write new data to the emulated EEPROM, into those same bytes that were partially updated before the reset/power failure

The point that @Sam stephan​ was making is that you can't trust those locations to be writable with any value other than all zeros unless you can absolutely control when the STM32 is reset or looses power.

** "any bit pattern" except all zeros.

[ArnoutDekimo]

I might be off here, but I'd like to understand the impact of this. I was considering using x-cube-eeprom, but then found this topic. If I am correct:

- This library defaults to writing 64 0-bits every boot to guarantee data integrity. => If the device ever ends up in a boot loop, it destroys itself after a while? (even though the software would otherwise not touch the fake eeprom by default)

- Regarding the comments of RM0351 - that's pretty vague. It sounds as if in the event of powerloss during write, the -entire- flash becomes unreliable. I would imagine the effect is limited to only that page.. ?

- And if so, having a much less performant but much simpler algorithm of just switching an eeprom buffer between two pages (with an incrementing header number distinguishing the most recent page) will perform eeprom emulation that does guarantee data retention in any condition without the risk of flash wear in a boot loop, correct?

(- I quickly glanced at what the STM32 arduino seems to do  (you'd think quite some ppl tested that before, and I was curious to see what they implemented) (https://github.com/stm32duino/Arduino_Core_STM32/blob/main/libraries/EEPROM/src/utility/stm32_eeprom.c), and as far as I see, they just erase a single page and write back to it, not guaranteeing any data retention in that powerloss+flash write condition. That was disappointing. )

For now, unless I need the bundling of data writes in a single page to get a much larger lifetime vs the ping-pong buffer approach, I think I will just stick with the single 2-page-alternation, but knowing that this flash corruption is limited to a single page would be some reassurance..

Thanks for any feedback

[ArnoutDekimo]

(And by the way, for anyone reading this for the first time, perhaps this helps to more quickly absorb the info):

- flash line: amount of bytes to be e.g. written/read in one go (halfword,double word, ..)
- the flash line "not being writable" => Bits can only be flipped down (unless reerased). But even though the data looks like 0xFFFF , this is not guaranteed to be the case (due to this effect)

- Hence the generic issue of how to reliably append to a single page with possibly this "invisible" locking effect (meaning that some bits are already flipped without seeing them flipped -- and flipping all-bits-in-the-flashline-down is the only thing that is reliable)