1

I've inherited an eeprom library for STM32 for an i2c device which is using the HAL_I2C_Mem_xxx library. What i've noticed is that for each saved parameter there are 2 copies of it. So in total 3 times the same value.

I was wondering if this is a safety mechanism to avoid wrong data to be written/read and if this is the state of the art when using an eeprom over i2c.

What's not completely clear is the following as well:

1. After each read call, all the 3 values are read and if the return state from the HAL_I2C_Mem_Read is different than HAL_OK, all the 3 values are overwritten in the memory with a default value --> shouldn't be better to retry a read call first?
2. If the read call returns 3 different values, all the 3 values are overwritten with a default value --> this could be the safest solution
3. If the last one in memory is equal to 1 of the 2 values and within boundaries, the last one in mem is copied to the one which is different so all 3 of them are equals. If outside boundaries the default is written in all of them.
4. If the first two are equal and the first in memory is within boundaries, the first one is written in the last one in memory.If outside boundaries the default is written in all of them.

Is all of this really needed nowadays?

Regards,

Luigi
  • 376
  • 3
  • 16

1 Answers1

1
I was wondering if this is a safety mechanism to avoid wrong data to be written/read
and if this is the state of the art when using an eeprom over i2c.

Well, I am working in an application with STM32 + eeprom too and had exactly these same questions, after some search I fould out that EEPROM do need some kind of value checking, as they are succsetible to bitflip, and altought there are more elegant ways of ensuring data integrity (as ECC), this method is proven to be effective and simple to implement, so in my opinion this will "do the job", (this method is even used by engine ECUs to store data in EEPROM).

I also agree with your points in 1, 2, 3 and 4.

In my case I gave up using EEPROM to store parameters and I will left the eeprom unpopulated in PCB, instead, I will emulate EEPROM in FLASH, as this will be less succetible to bitflipping (not needing to store 3 times each value) and communication errors (I2C is really buggy sometimes)

I am still coding my EEPROM emulation, but the way it works is based on the application note AN2594 from ST ( http://www.st.com/en/embedded-software/stsw-stm32010.html ). Also, the code described in the AN is included in the HAL library package, which in my computer islocated in: STM32Cube_FW_F1_V1.4.0\Projects\STM32F103RB-Nucleo\Applications\EEPROM\EEPROM_Emulation

Gustavo Laureano
  • 556
  • 2
  • 10