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.