eeprom overflow

Question

I was using STM32f401RE,and i stored a series of numbers into the AT24c512, EEPROM read and write operations on several times during the implementation of the code is done, about 10,000 times each code execution. In the beginning, the numbers of EEPROM read correctly and are properly written on it.

But when that device will remain lit for about 5 to 6 hours and the EEPROM data can be written and read by the microcontroller not receive the right numbers.

For example, 500 should be written on EEPROM, but that number is read from the EEPROM is 1,589,436. That by turning off the device or writing the new numbers will not be output correctly. In your opinion what is the problem? How do I fix this?

• brhans: Did you read the datasheet to check what the write endurance spec is for your EEPROM? Its right there on the 1st page.
• jms: EEPROMs have a limited lifespan in memory writes; each bit of an AT24c512 is specified to endure 100000 write cycles. There is likely a large margin above the specified 100000 writes, but eventually you will wear out the storage if you do nothing but write data to the same addresses over and over for 6 hours.
• Mehrshad: now how can i read and write my data? now i cant use EEPROM
• Anonymous: Why you have chosen to use EEPROM? Why not RAM?
• mic: @Mehrshad: Think about a different strategy. I can't imagine that it's really necessary to write/erase that often to a non volatile memory, but if so, other technologies may be the better choice. For instance, have a look at this: ti.com/lit/an/slaa526a/slaa526a.pdf

Answer 1

It seems you are wearing out the EEPROM. All such floating-gate memory cells have a finite number of times they can be written and erased before they are irreparably damaged. Check the datasheet. It should give the guaranteed minimum "lifetime" values for writes and erases.

Most pure EEPROMs are rated for considerably more than 10,000 such operations. However, that is what your code is apparently doing each time. And, especially during development and debugging, it is quite possible that something got run in a loop and performed these operations many times.

Your EEPROM is toast, done, worn out. If you replace it with a new chip and the problem goes away (temporarily), then that is definitely what happened.

In general, if you require frequent updating of non-volatile data, you need to do something other than just blindly hook up a EEPROM. The first strategy is to change the architecture so that non-volatile state doesn't need to be updated so often. If that is impossible, then you either live with the limited lifetime or use a different technology.

Something else to look into is how exactly the firmware is writing to the EEPROM. These things usually have "pages" that are electrically erased or written at one time. Sometimes writing individual bytes is possible, but it still counts as one event for the whole page.

The firmware therefore needs to be smart about how writes are done. I usually create interface routines that allow individual bytes to be read or written at random. However, underneath they really cache one whole page. Writes don't go to the physical EEPROM until a different page is needed or until the explicit FLUSH routine is called. Sometimes the FLUSH routine is called automatically by a timer.

However, in all cases you don't do a physical write when no value is being changed. I keep a "dirty" bit that indicates whether the cached page has been changed since being read from the EEPROM. When going to a different page, no write is done if the current cache isn't dirty. There is also logic to check for individual byte writes not changing the cached value. In that case, the dirty flag is not set.

Proper low level EEPROM access routines can help, but the application has to be aware of the non-volatile memory limitations too. You should try to avoid, for example, jumping around all over the address space writing small numbers of bytes. If you have to do a large write, take care to do it sequentially.

Of course you simply can't write a new value every second, for example, and expect a 100,000 write lifetime device to last more than 28 hours. Even a 1,000,000 write lifetime device wouldn't even last 12 days in this case.

• Mehrshad: thank you, now i need save numbers and this numbers is very important, so when power is low or board is reset this numbers Should not be erase. at this time how can i save this numbers and read them? while i must read and write many and many.
• jms: @Mehrshad You could keep the data in RAM and write the RAM contents to the EEPROM once you detect that the power supply has become unavailable. On power up, you'd copy the EEPROM data to RAM. Of course you will need to power the EEPROM and processor somehow when the power is removed until the data transfer is complete, a large-ish capacitor fed by a schottky diode should suffice.
• Mehrshad: ok, how can i detect that the power supply has become unavailable?I working with STM32F401RE
• jms: @Mehrshad While your microcontroller doens't have an analog comparator, you can use the ADC to convert the input voltage to a digital value. As the input voltage is most likely higher than the supply voltage of the microcontroller, you need a voltage divider in order to measure it, somewhat like this. This specific ADC also has a feature just for cases like this: the analog watchdog. It can be configured to generate an interrupt when the input voltage goes out of a specific range.
• Mehrshad: @Olin Lathrop can i using internal SRAM instead of EEPROM?