October 12, 2015 at 14:27How to Avoid EEPROM Wear
- Tutorial
Summary: If you periodically update a value in the EEPROM every few minutes (or several seconds), you may run into the problem of the wear of the EEPROM cells. To avoid this, you need to reduce the frequency of entries in the cell. For some types of EEPROM, even recording speeds more than once per hour can be a problem.
EEPROM is commonly used to save settings and logs on embedded systems. For example, you might want the black box feature to record the latest data at the time of an accident or loss of power. I have seen specifications requiring the recording of such data every few seconds.
But the problem is that the EEPROM has a limited record number resource. After 100,000 or a million records (depending on the specific chip), some of your systems will begin to experience problems with EEPROM failure. (Look in the datasheet for a specific number. If you want to release a large number of devices, the “worst case” is probably more important than the “typical” one). A million records seem like a big number, but in fact it will end very quickly. Let's look at an example, assuming that we need to store the measured voltage in one cell every 15 seconds.
1,000,000 records with one record in 15 seconds give records per minute:
1,000,000 / (4 * 60 minutes / hour * 24 hours / day) = 173.6 days.
In other words, your EEPROM will run out of reserves of a million records in less than 6 months.
Below is a graph showing the time to wear (in years) based on the update period of a particular EEPROM cell. The limit line for a product with a life expectancy of 10 years is one update every 5 minutes 15 seconds for a chip with a resource of 1 million records. For an EEPROM with a resource of 100K, you can update a specific cell no more than once every 52 minutes. This means that you should not hope to update the cell every few seconds if you want your product to work for years, not months. The above scales linearly, however, in this device there are also secondary factors, such as temperature and access mode.
The most painless way to solve the problem is to simply write data less often. In some cases, system requirements allow this. Or you can record only with any major changes. However, with an event-bound entry, be aware of a possible scenario in which the value will constantly fluctuate and cause a stream of events that will lead to EEPROM wear.
(It will be nice if you can determine how many times an EEPROM has been recorded. But this will require a counter that will be stored in the EEPROM ... and the problem turns into a counter wear problem.)
Some processors have a low power interrupt that can be used to write one last value to the EEPROM, while the system shuts down due to loss of power. In general, you store the value of interest in RAM, and save it in the EEPROM only when the power is turned off. Or perhaps you write the EEPROM from time to time, and write another copy to the EEPROM as part of the shutdown procedure to make sure that the most recent data is written.
It is important to make sure that there is a large power capacitor that will maintain a voltage sufficient to program the EEPROM for a sufficiently long time. This might work if you need to write one or two values, but not a large block of data. Caution, there is plenty of room for error!
The classic solution to the wear problem is to use the FIFO ring buffer containing N last value entries. You also need to save a pointer to the end of the buffer in the EEPROM. This reduces EEPROM wear by a value proportional to the number of copies in this buffer. For example, if a buffer goes through 10 different addresses to save a single value, each particular cell is modified 10 times less and the write resource increases 10 times. You will also need a separate counter or time stamp for each of the 10 copies, so that you can determine which one is the last at the time of shutdown. In other words, you need two buffers, one for the value, and one for the counter. (If you save the counter at the same address, this will lead to its deterioration, because it should increase with each recording cycle.) The disadvantage of this method is that you need 10 times more space to get 10 times longer life. You can be smart, and pack the counter along with the data. If you write a large amount of data, adding a few bytes to the counter is not such a big problem. But in any case, you will need a lot of EEPROM.
Atmel has prepared an appnote containing all the bloody details:
AVR-101: High Endurance EEPROM Storage: www.atmel.com/images/doc2526.pdf
A special case for the counter of the number of records
Sometimes you need to save the counter, not the values themselves. For example, you may want to know the number of times the device was turned on, or the operating time of your device. The worst thing about counters is that they are constantly changing the least significant bit, worn out the lower EEPROM cells faster. But here it’s possible to apply some tricks. There are several smart ideas in the applet from Microchip, such as using a Gray code so that only one bit from a multibyte counter changes when the counter value changes. They also recommend the use of corrective codes to compensate for wear. (I do not know how effective the use of such codes will be, because it will depend on how independent the errors in the bits in the bytes of the counter are, use at your own risk, approx. Author). See Appnote:ww1.microchip.com/downloads/en/AppNotes/01449A.pdf
Note: for those who would like to know more, Microchip has prepared a document containing detailed information on the arrangement of EEPROM cells and their wear with diagrams:
ftp.microchip.com/tools /memory/total50/tutorial.html
Let me know if you have any interesting ideas on anti-wear EEPROM.
Source: Phil Koopman, Better Embedded System SW
Betterembsw.blogspot.ru/2015/07/avoiding-eeprom-wearout.html
Translator's note: in recent years, EEPROM chips have appeared with a page-wipe organization (similar to FLASH chips), where you can logically address cells (read, write, and erase) byte-by-bye, but the chip erases the entire page invisibly to the user and overwrites it with new data. Those. Having erased the cells at address 0, we actually erased and rewritten the cells with addresses 0 ... 255 (with a page size of 256 bytes), so the buffer trick will not help in this case. When the record resource of such a microcircuit is exhausted, not one cell fails, but the entire page. In datasheets for such microcircuits, the recording resource is indicated for the page , and not for a specific cell. See, for example, datasheet on 25LC1024 from Microchip.
When you record data, time flies fast
EEPROM is commonly used to save settings and logs on embedded systems. For example, you might want the black box feature to record the latest data at the time of an accident or loss of power. I have seen specifications requiring the recording of such data every few seconds.
But the problem is that the EEPROM has a limited record number resource. After 100,000 or a million records (depending on the specific chip), some of your systems will begin to experience problems with EEPROM failure. (Look in the datasheet for a specific number. If you want to release a large number of devices, the “worst case” is probably more important than the “typical” one). A million records seem like a big number, but in fact it will end very quickly. Let's look at an example, assuming that we need to store the measured voltage in one cell every 15 seconds.
1,000,000 records with one record in 15 seconds give records per minute:
1,000,000 / (4 * 60 minutes / hour * 24 hours / day) = 173.6 days.
In other words, your EEPROM will run out of reserves of a million records in less than 6 months.
Below is a graph showing the time to wear (in years) based on the update period of a particular EEPROM cell. The limit line for a product with a life expectancy of 10 years is one update every 5 minutes 15 seconds for a chip with a resource of 1 million records. For an EEPROM with a resource of 100K, you can update a specific cell no more than once every 52 minutes. This means that you should not hope to update the cell every few seconds if you want your product to work for years, not months. The above scales linearly, however, in this device there are also secondary factors, such as temperature and access mode.
Decrease frequency
The most painless way to solve the problem is to simply write data less often. In some cases, system requirements allow this. Or you can record only with any major changes. However, with an event-bound entry, be aware of a possible scenario in which the value will constantly fluctuate and cause a stream of events that will lead to EEPROM wear.
(It will be nice if you can determine how many times an EEPROM has been recorded. But this will require a counter that will be stored in the EEPROM ... and the problem turns into a counter wear problem.)
Nutrition Reduction Interruption
Some processors have a low power interrupt that can be used to write one last value to the EEPROM, while the system shuts down due to loss of power. In general, you store the value of interest in RAM, and save it in the EEPROM only when the power is turned off. Or perhaps you write the EEPROM from time to time, and write another copy to the EEPROM as part of the shutdown procedure to make sure that the most recent data is written.
It is important to make sure that there is a large power capacitor that will maintain a voltage sufficient to program the EEPROM for a sufficiently long time. This might work if you need to write one or two values, but not a large block of data. Caution, there is plenty of room for error!
Ring buffer
The classic solution to the wear problem is to use the FIFO ring buffer containing N last value entries. You also need to save a pointer to the end of the buffer in the EEPROM. This reduces EEPROM wear by a value proportional to the number of copies in this buffer. For example, if a buffer goes through 10 different addresses to save a single value, each particular cell is modified 10 times less and the write resource increases 10 times. You will also need a separate counter or time stamp for each of the 10 copies, so that you can determine which one is the last at the time of shutdown. In other words, you need two buffers, one for the value, and one for the counter. (If you save the counter at the same address, this will lead to its deterioration, because it should increase with each recording cycle.) The disadvantage of this method is that you need 10 times more space to get 10 times longer life. You can be smart, and pack the counter along with the data. If you write a large amount of data, adding a few bytes to the counter is not such a big problem. But in any case, you will need a lot of EEPROM.
Atmel has prepared an appnote containing all the bloody details:
AVR-101: High Endurance EEPROM Storage: www.atmel.com/images/doc2526.pdf
A special case for the counter of the number of records
Sometimes you need to save the counter, not the values themselves. For example, you may want to know the number of times the device was turned on, or the operating time of your device. The worst thing about counters is that they are constantly changing the least significant bit, worn out the lower EEPROM cells faster. But here it’s possible to apply some tricks. There are several smart ideas in the applet from Microchip, such as using a Gray code so that only one bit from a multibyte counter changes when the counter value changes. They also recommend the use of corrective codes to compensate for wear. (I do not know how effective the use of such codes will be, because it will depend on how independent the errors in the bits in the bytes of the counter are, use at your own risk, approx. Author). See Appnote:ww1.microchip.com/downloads/en/AppNotes/01449A.pdf
Note: for those who would like to know more, Microchip has prepared a document containing detailed information on the arrangement of EEPROM cells and their wear with diagrams:
ftp.microchip.com/tools /memory/total50/tutorial.html
Let me know if you have any interesting ideas on anti-wear EEPROM.
Source: Phil Koopman, Better Embedded System SW
Betterembsw.blogspot.ru/2015/07/avoiding-eeprom-wearout.html
Translator's note: in recent years, EEPROM chips have appeared with a page-wipe organization (similar to FLASH chips), where you can logically address cells (read, write, and erase) byte-by-bye, but the chip erases the entire page invisibly to the user and overwrites it with new data. Those. Having erased the cells at address 0, we actually erased and rewritten the cells with addresses 0 ... 255 (with a page size of 256 bytes), so the buffer trick will not help in this case. When the record resource of such a microcircuit is exhausted, not one cell fails, but the entire page. In datasheets for such microcircuits, the recording resource is indicated for the page , and not for a specific cell. See, for example, datasheet on 25LC1024 from Microchip.