The impact of continuous writing on the EEPROM IC

[User16715311169089326328]

1.I previously developed a product that, due to a program bug, continuously wrote to a fixed address in the EEPROM  IC (M24C64-F) every 25ms while in standby mode. After about 1 to 2 years of the product being sold, we got feedback from those issue that certain control parameters in the EEPROM IC (not the aforementioned fixed address) were being altered. We conducted tests on the affected products from the issue (e.g., power interruptions, noise interference, normal power ON/OFF, etc.), but we were unable to reproduce the issue. Could somebody tell under what conditions the control parameters in the EEPROM IC could be altered?

2.Is the process of writing to EEPROM the most frangible time for an EEPROM IC? if so, power interruption, electrical noise or other interference occurs at this time, will it cause other address data to be modified?

[Uwe Bonnes]

You should have  a look at the datasheet and "Write cycle endurance". 4e6 cycles are specified, with a 40 Hz write cfrequency you reach this value already in one day => fix youy bug!

[Andrew Neil]

---

@User16715311169089326328 wrote:

certain control parameters in the EEPROM IC (not the aforementioned fixed address) were being altered.

---

What, exactly, do you mean by that?

• What parameters?
• In what way(s) were they "altered"?
• How did you determine that they were "altered"?

[unsigned_char_array]

Like @Uwe Bonnes wrote you are exceeding the write cycle limits of your EEPROM.

The solution is to limit number of writes or implement some form of wear leveling to spread them over multiple bytes.

You can limit how often parameters are changed or only write them when you turn off the unit (you would need to be able to detect drop in supply voltage).

Wear leveling only needs to be enabled on the most frequently updated parameters. One way is to store the variable as a pair of data and a byte in an array. You use the byte to detect the most current one. For instance: 0xFF is not initialized, first time it's set to 0, second time to 1, third time to 0 again, etc. The first byte that differs from the next is the most recent one, unless they are all the same, then the last one is the most recent one. Be sure to first write the data, then the byte to make it atomic.

Like this:

no byte stored yet:
byte, data
0xFF,0xFF
0xFF,0xFF
0xFF,0xFF
0xFF,0xFF

1 byte stored, index 0 is most recent:
byte, data
0x00,0x01
0xFF,0xFF
0xFF,0xFF
0xFF,0xFF

1 byte stored, index 0 is most recent (partial write):
byte, data
0x00,0x01
0xFF,0x02
0xFF,0xFF
0xFF,0xFF


2 bytes stored, index 1 is most recent:
byte, data
0x00,0x01
0x00,0x02
0xFF,0xFF
0xFF,0xFF

at least 4 bytes stored, index 3 is most recent:
byte, data
0x00,0x01
0x00,0x02
0x00,0x03
0x00,0x04


at least 4 bytes stored, index 0 is most recent:
byte, data
0x01,0x01
0x00,0x02
0x00,0x03
0x00,0x04

at least 4 bytes stored, index 1 is most recent:
byte, data
0x01,0x01
0x01,0x02
0x00,0x03
0x00,0x04

at least 4 bytes stored, index 2 is most recent:
byte, data
0x01,0x01
0x01,0x02
0x01,0x03
0x00,0x04​

This would increase number of write times by a factor 4, but takes 8 times as much space. Larger data blocks have less overhead.

More advanced wear leveling uses dead sector detection. You could use bitfields for that or something so 1 byte per 8 blocks. I'm sure you can find examples.

I cannot comment on why bytes in different places are affected by exceeding limits in other areas. With a 200-years data retention they shouldn't get corrupted by themselves in 2 years, so there is something else going on. But outside specs is outside specs and you can get undefined behavior.

[Tesla DeLorean]

+1 definitely this

When using old X1286 (RTC/EEPROM) Intersil when we first used as I recall, and then subsequent mergers/acquisitions.

https://www.renesas.com/us/en/document/dst/x1286-datasheet

They had 32KB, but the data we had to keep current/recent copies of could be kept in a small structure and then journalled across the available array in a loop, so wear wasn't localized. Only written when changed.

High frequency stuff better to use RTC/BBR/NVRAM type memories.

Not sure there's a good current replacement for this type of combination part, it used older process technologies and was harder to replicate function / performance in newer ones.

[unsigned_char_array]

In addition the problem can also be an I2C bitflip. In 2 years and literally billions of I2C writes 1 address bit could have flipped and data written to the wrong sector in EEPROM. Especially with too high pullup resistors the rise time may be too low and immunity to external fields might not be good enough. Or dip or spikes off the power supply. Don't you think?

[Techn]

There are some bytes in the battery backed ram for stm32,  you can write the data which changes at this rate and make backup to EEPROM once in day or when you change the battery for example.  

[User16715311169089326328]

Hello Uwe Bonnes:

  The point of my issue is not the bug, because the bug has been fixed. My issue is, in addition to this kind of continuous writing, what else can affect the error of the controller inside the EEPROM?

[User16715311169089326328]

Hello Neil:
What parameters?
    A:The value stored in EEPROM for control
In what way(s) were they "altered"?
    A:So far I don’t know the exact reason
How did you determine that they were "altered"?
    A: Use the EEPROM IC reading tool to compare the value read with the original set value

[User16715311169089326328]

Hello unsigned_char_array:

Thanks  for your suggestions. I might ref them in the future.