Can anyone point me to some techniques to extend the life of an EEPROM that has to maintain a counter? I need a non-volatile 7 or 8 bit counter that has to be incremented at least 8 million times. (The write endurance of my EEPROM is one million). Hardware re-design is not possible. No battery-backed RAM is available. Power may be lost at any point without warning. I can have maybe 16 bytes or so of EEPROM to implement this counter.
I seem to remember an article in one of the magazines, but cannot find it anymore. I'm working on a scheme, but it would save some time to see another approach.
"Darcy Roberts" ha scritto nel messaggio news: snipped-for-privacy@ag-instruments.com...
If the counter increments by one at each writing in eeprom, perhaps you could:
- at reset, read all the 16 locations; initialize your counter in ram using the highest value you read. Take care of rollovers...
- remember the position where you found the highest
- at each increment, write the new value in the successive slot, wrapping around at the end of the 16 slots.
- you'll need to initialize the eeprom to 00 during initial startup
- if not needed, you could use the 8th bit as a checksum, or...
- ..given you need 8 million writings, and you have 16 locations, you could afford to use two bytes for each counter value. You could code the value using an error correcting code (hamming...)
or simply put in the socket a ferroelectric memory (ramtron), you should be able to find a pin-to-pin replacement: 1 giga of writings... and forget about that.
download the HC908AZ60A Datasheet @ motorola read chapter 6.5.5 and table 6.2 about selective bit programming scheme but I am not shure if this flowchart is valid for all Eeproms. Is your pro- gramming/erase based on the Nordheim Fowler or hot electron injection?
You need 8 million write cycles, and you only have one million write cycles per byte.
This means you have to use at least eight bytes. I'd use the full sixteen: that would give me sixteen million write cycles to play with.
During manufacturing, zero all sixteen bytes.
When it comes time to "increment" the "counter", scan the bytes from first to last. If they all contain the same value, increment and rewrite the FIRST byte, otherwise, increment the FIRST byte that has a DIFFERENT value from the one below it. Your counter is eight bits of whatever plus 4 bits of sort-of ring counter.
There are probably better ways to do it, but the key is to minimize the number of writes.
You can find in the archives of this newsgroup a thread of 15 articles that addressed this issue in Aug. of 1999. Here is what I wrote back then: (Notice that it gives a solution that does not even require the use of the extra number of EEPROM bytes that you have.)
- - - - - - - - - - - - - -
An optimal counting method for EEPROM counters depends somewhat on the resolution of the erase operation, since, as I understand it, the erase operation is what does the damage that accumulates in the EEPROM until it finally fails. I don't know what is most common, but let's assume that the erase resolution is one byte. That means if you are turning any '1' bits to '0' bits in a byte then the entire byte will be subjected to the stress of an erasure. If that is the case, then if you count normally, the LSB gets no more erasure stress than any other bit in that byte. So a gray code at the bit level is of no particular advantage. The normal binary counting sequence 00...ff has 128 erasures in one complete cycle. The standard gray code sequence 00 01 03 02 06 07 05 04 ... 80 also has 128 erasures in a complete cycle.
So here's a proposal. Let's make every erasure worthwhile. That is, delay '1' to '0' transitions as long as possible.
Here is the beginning of a better sequence of all 256 byte values. There is an erasure at the end of each row:
00 01 03 07 0f 1f 3f 7f ff
02 06 0e 1e 3e 7e fe
04 05 0d 1d 3d 7d fd
08 09 19 39 79 f9 fb
10 11 13 17 37 77 f7
21 21 23 27 2f 6f ef
40 41 43 47 4f 5f bf
80 81 83 87 8f cf df
0c 1c 3c 7c fc
12 32 72 f2 f3
42 62 e2 e6 f6
82 86 8e ce ee
84 85 c5 e5 f5 ...etc.
This is very tedious, but I suspect that this sequence can be completed to give all 256 values with only about 50 erasures. It is quite easy to prove that no sequence can be found that has less than 32 erasures, so the optimal value is somewhere between 32 and 50 erasures for 128 counts. Compared to the binary count sequence which has 128 erasures, this is at least a 2.5-fold improvement.
Let's define the effectiveness of the counting method as the total count divided by the number of erasures per byte necessary to reach that count. For a single byte binary counter, the effectiveness is 256 / 128 = 2. For the sequence shown above the effectiveness is
256 / 50 = 5.12.
Now let's combine the single byte count sequence with about 50 erasures to make a two-byte counter. For a two-byte counter we need to define a sequence of byte pairs (A,B) where the transition from one pair to the next is a byte sequence transition for A or B. Here is the algorithm for listing all 65536 pairs in a sequence that changes only A or B. Start with A=0 and B=0. Then alternate between advancing A and advancing B (in the special sequence defined above) until such an advancement would result in a previously encountered (A,B) pair. When that happens, continue advancing the same byte two more times, then resume alternation. This will hit every (A,B) pair once and only once. [[An easy way to see why this works is to draw an 8x8 checkerboard and start in the upper-left corner. Then, by moving right, then down, then right, then down again, zig-zag down the diagonal. When you get to the end of a row or column, wrap around to be beginning of that row or column. When you get to the bottom left corner, you cannot go down because that would put you in the starting position, so you have to continue going right. So go right two more times, then start going down. In this manner you will visit every square on the checkerboard.]]
The erasures are not exactly balanced between the two bytes because the same byte is always advanced 2 extra times in the event of a collision. But collision events are rare, so the erasure experience is about the same with the two bytes. The number of erasures is still about 19% of the number of counts. For 65536 counts this amounts to 12800 erasures, or about 6400 erasures per byte. Thus, using the previously defined effectiveness formula, the effectiveness of the 2-byte counter is
65536 / 6400 = 10.24, which is twice as effective as a 1-byte counter, and 5 times as effective as an ordinary
2-byte binary counter.
This method can be used to combine two 2-byte counters to make a 4-byte counter with 4,294,967,296 counts and about
204,000,000 erasures per byte. The effectiveness of this
4-byte counter is 20.4, which is twice as effective as a 2-byte counter and 10.2 times as effective as an ordinary
4-byte binary counter.
Notice that as you increase the number of bytes in the counter, the number of erasures per byte per 1000 counts goes down linearly with the number of bytes in the counter.
In all these proposals I am assuming that the desired counting sequence must have as many counts as the binary counter of the same number of bytes. It may turn out that incomplete sequences might actually have higher effectiveness ratings, but I will leave that area open for others to investigate. For now, I think a 10.2 improvement over binary is pretty good.
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
Some connents - write endurance specs are a statistical reference, and it is not a step function. Thus you need some detection and flag method for 'worn' cells, and a read-after-write check.
It's not clear if failure stress is pattern related, but if you guess that it is, then a binary counter 'spins' the LSB at the count rate. A Gray counter halves that toggle rate.
If you can use 7bit, then allocate the 8th as a parity bit.
So, that looks like 14 bytes of counters, 2 bytes of 'Worn' flags and a 'rotate unless worn' scheme, that spreads the cell toggle rate. That should tolerate the statistical nature of failures.
The simple and efficient way is to do write behind cashing to EEPROM. Just update EEPROM once per 10 sec instead of updating it every time you modify the value. In the worst case you are losing only the last 10 sec of information. The other tip is to do read before write, and do the actual update only if the byte in EEPROM is different from what you are trying to write. That trick saves a lot of update time and write cycles.
Nothing about extending the life of EEPROM usage, but re. losing power at any time, this is an approach I use - Is there a flaw in this?...
Store 2 copies of the counter with associated valid flags for each copy. When you write the counter to EEPROM, store it twice: For the first copy, set its valid flag to false, store counter in the first copy, then set the valid flag to true. Now repeat for the second copy. In this way, there should always be a valid copy of the counter in EEPROM.
At power-up, check if the valid flag of the first copy is true, if so load the counter from that copy. Otherwise, load it from the second copy.
In my case, I've used an 8-bit value for the valid flags to indicate validity (i.e. not just a single bit), to lower the risk of an accidental valid flag.
Does anyone know for a fact if EEPROM endurance is a function of the number of writes or the number of erasures? That is, if I do many writes (always changing 0's to 1's but not changing any 1's to 0's), but only do a few erases (changing 1's to 0's) is the EEPROM endurance going to be affected by the writes or the erasures?
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
The default value after an erase operation is all the bits to '1'. And for the endurance, it seems to be the write operations AND the erase operations (see in a MICROCHIP EEPROM datasheet).
Yvan
************************ YBDesign
formatting link
************************
Robert Scott a écrit dans le message : snipped-for-privacy@news.wwnet.net...
The datasheet for the 24LC128 (the part I'm using) says "1,000,000 erase/write cycles guaranteed." This implies to me that both write and erase are significant.
The datasheet guarantees 1x10^6 erase/write cycles. One of the problems with some techniques, not necessarily yours below, is that without error checking (parity or a block check), it doesn't address the problem of 'fading'. That is, the read after write works okay, but might fail some time after, due to leakage or other mechanism.
They could just be saying that because in most applications, there are as many erasures as writes. But it still does not answer the question as to which operation is most responsible for the degradation.
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
I suspect, but don't know, that most EEPROM implementations do a byte erasure as part of every write operation, whether needed or not. If so, the question then becomes is there more wear in writing and erasing a 0 bit than writing and erasing a 1 bit. Basically, you need an operations and failure model to work from.
That may well not be an option, depending on the particular type of EEPROM being used. Some can only clear all bits in a whole page at once, and then set them individually (or vice versa). So once you're at 0xff, you would *have* to move on to 0x00 as the next step, anyway.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Hans-Bernhard Broeker wrote in news:bgrcpm $ftk$ snipped-for-privacy@nets3.rz.RWTH-Aachen.DE:
Well, modifiy it to suit the erase state of your particular EEPROM. All the ones I have worked with have been erase state of all 1's. Some allowed you to overwrite without erasing, but only if you are clearing bits, some automatically erased when you did a write.
FLASH and EEPROM's "erased" state is 1, not 0. You "write" 1 to 0, and you "erase" 0 to 1.
You should avoid writing a bit twice without prior erasing. This can be done by ANDing the new word with the old word. Those chips that could be damaged by "deep writing" a bit over and over, probably have such an AND protection already built-in. Check the datasheet.
Many EEPROMs, especially the smaller 24C/93C devices, have no command to write-without-erase. That is, whenever you write a word, the cells are automatically erased, then written. That's a full cycle :-(
More often than not, there's no spec in the datasheet for you to rely on. When you contact the manufacturer, you often get a positive answer, though. If you don't ask, you're on your own (although most chips support it).
I asked Atmel about their AT45 dataflash. Although there's nothing in the datasheet, they confirmed to me that it is safe to do incremential writes. Only the "erase" cycles reduce lifetime.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.