X-CUBE-EEPROM software package, fills in zeros into emulated EEPROM on every reset.

[MGrub.3]

I am using STM32L476, and I downloaded X-CUBE-EEPROM software package, included it into my project and it works fine. But I am noticing that after every reset it writes dummy word of all 0. CRC + Vaddress +Data... all 32 bits are zeros.

That write is issued from EE_Init() Step 8. Here is code snippet. 

/*********************************************************************/
 /* Step 8: Perform dummy write '0' to get rid of potential */
 /* instability of line value 0xFFFFFFFF consecutive to a */
 /* reset during write here */
 /* Only needed if recovery transfer did not occured */
 /*********************************************************************/
 if (recoverytransfer == 0U)
 {
 status = VerifyPagesFullWriteVariable(0U, 0U);
 
 /* The dummy write can be skipped in case pages are full
 because in this case potential instability can not happen */
 if ((status != EE_OK) && (status != EE_PAGE_FULL))
 {
 return EE_WRITE_ERROR;
 }
 }

Function VerifyPagesFullWriteVariable(0U, 0U); writes dummy 0’s.

Why is this done every reset? It slowly fills up my EEPROM with 0. It happens even if page is still in Active mode and there is a plenty of space to store new data in. There was no need for transfer.

This is how my EEPROM memory looks. I have some data with data zero values in first two locations, and next two locations are all zeros. And it keeps adding all zeros after every reset.

[prain]

which flash pages are you using? try to use the last two flash pages of your MCU​ and check again. Maybe you are writing to a flash page that already used for another purpose (for example firmware code).

[MGrub.3]

I didn't change code from X-CUBE-EEPROM software package, so EEPROM starts at 0x08080000. The rest of my application is just basic. Not much of flash is taken by the application code which starts at 0x08000000.

[B Zikhali]

I have noticed exactly the same issue. On each bootup and entire line of 0's is written to the page and slowly fills up the eEEPROM triggering useless switches.

[SOfne.1]

I have noticed the same issue, too. Fortunately this behavior stops when the end of a flash page is reached (no page transfer is issued in this case).

Nevertheless this wears out the internal flash needlessly, because then a single data write of my application triggers a whole page transfer and the filling up with 0's starts again.

[StéphaneM]

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