Extended life of EEPROM counter?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Greetings all:

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

Re: Extended life of EEPROM counter?
Quoted text here. Click to load it

If the counter increments by one at each writing in eeprom, perhaps you

- 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.

Re: Extended life of EEPROM counter?
Quoted text here. Click to load it

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?


Re: Extended life of EEPROM counter?
Quoted text here. Click to load it

Off the top of my head.

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.

Re: Extended life of EEPROM counter?

Quoted text here. Click to load it

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.

Vladimir Vassilevsky, Ph.D.

DSP and Mixed Signal Design Consultant


Re: Extended life of EEPROM counter?
Quoted text here. Click to load it

Vladimir, he specifically said "counter".  To me, that implies that he's
planning on changing the value EVERY time he writes it, and it also implies
that he wants to see EVERY value.  *IF* he has a good power-down sequence,
and *IF* he has a good power supply that will keep everything alive and
stable long enough, THEN it makes sense to do write-behind caching.  In my
experience, those are two very big IFs.  With the modern preference for
switching power supplies, as opposed to the old huge heavy(!) linear
supplies with filter capacitors the size of vodka bottles, I would not want
to rely on very much time at all after the power-down warning came.

Re: Extended life of EEPROM counter?
On Tue, 05 Aug 2003 15:07:55 -0400, Darcy Roberts

Quoted text here. Click to load it

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

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

Re: Extended life of EEPROM counter?
Quoted text here. Click to load it

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
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.


Re: Extended life of EEPROM counter?
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.

Darcy Roberts

Jim Granville wrote:
Quoted text here. Click to load it

Re: Extended life of EEPROM counter?
On Wed, 06 Aug 2003 10:21:31 -0400, Darcy Roberts

Quoted text here. Click to load it

It seems to me that this "fading" is directly related to the EEPROM
write/erase duration (1,000,000 in your case). For EEPROMs it
represents the breakdown of the floating gate barrier that maintains
charge retention. However for any variable data that is stored on
non-volatile memory I would think that some form of data integrity
check (checksum, CRC, etc) is required.

Caching of the data in RAM has been suggested in this thread and this
may be the most appropriate way of extending EEPROM life -- unless you
really want 8 million power cycles as a requirement!!?

For a 2-wire or I2C EEPROM it takes about 10 milliseconds to perform a
byte or page write. A page is typically 64 bytes so this means that
you can write 64 bytes (in the same row) in 10ms -- for your
requirement this should be adequate to store the counter value with
CRC or checksum. Allowing for other overhead, your requirement to the
Power Supply guy should be about 40 millisecond retention on the 5
volt supply (this is conservative). This should be achievable, even
with switching supplies.

Of course, your power-down sequence should be so that if promotes the
extension of power by:
o turning off all LEDs & displays
o turning off all backlights
o switching off any motors & stopping any PWM drives

Quoted text here. Click to load it

I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Extended life of EEPROM counter?

Quoted text here. Click to load it

If you can still think about a hardware change, a ferroelectric RAM (FRAM)
might be the answer. See e.g. <http://www.ramtron.com/ .

Tauno Voipio
tauno voipio @ iki fi

Re: Extended life of EEPROM counter?
Quoted text here. Click to load it

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.


EEPROM endurance question
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

Re: EEPROM endurance question
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).



Quoted text here. Click to load it
address is fake.)
Quoted text here. Click to load it

Re: EEPROM endurance question
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.

Darcy Roberts

Robert Scott wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it

Re: EEPROM endurance question
On Wed, 06 Aug 2003 10:12:56 -0400, Darcy Roberts

Quoted text here. Click to load it

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

Re: EEPROM endurance question
Quoted text here. Click to load it

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.


Re: EEPROM endurance question
Quoted text here. Click to load it

 Good point, another one to add to this, is what about same-page ?
Most EE's grab a (small) block of bytes, and rewrite that block.

 I do recall seeing in the rarely published actual failure stats,
that random single bit failures are the norm.
 So, single-bit tolerant designs should push the ceiling.

Darcy Roberts wrote:
Quoted text here. Click to load it

It's uncommon to not have a FIT rate hidden in there somewhere, as well
as a temperature bias.
Sounds like you should do your own tests...


Re: EEPROM endurance question
Quoted text here. Click to load it

In principle yes, but there are a few caveats:

1. FLASH and EEPROM's "erased" state is 1, not 0.  You "write" 1 to 0,
   and you "erase" 0 to 1.

2. 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.

3. 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 :-(

4. 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.


Re: EEPROM endurance question
On 6 Aug 2003 15:01:04 -0700, the renowned snipped-for-privacy@hotmail.com

Quoted text here. Click to load it

Microchip now seem to be recommending, for on-processor-chip EEPROM,
to refresh the contents periodically (which they define) if the memory
usage exceeds some fraction (10%?) of the expected life. The
implication is that with large numbers of writes the retention time
decreases substantially before you get outright failure.  

Best regards,
Spehro Pefhany
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline