Feedback to Forget Me Not! - Murphy's Law, Jun' 2001
return to Murphy's Law
There is a reference in the article to Ross Williams's "A Painless
Guide to CRC Error Detection", but no reference is given.
This document is an on-line guide and is available, in a number
of slightly different formats, on the Internet at any one of:
A number of readers mentioned various approaches to handling
EEPROMs that are limited in the number of write cycles that the
chip can handle. I neglected this topic in my original column,
since I was tring to stick to the higher level software issues,
and avoid the hardware and technology-specific stuff, but it is
an important issue, and probably should have gotten a mention.
Some of the mails follow:
Dear Niall Murphy,
I can relate to your article, Forget Me Not, in ESP June 2001.
I would like to add that you can not assume only a single byte
will be corrupted when power fails during an EEPROM write. We
have experienced multiple byte EEPROM corruption in the Atmel
ATmega103 microcontroller. For the revision of the ATmega103 we
used, the address registers EEARH and EEARL could change randomly
as power drops out, corrupting random multiple locations. Our
solution for this was to store factory calibration data in triplicate
and implement a voting algorithm to repair corruptions.
As an interesting side note, Atmel recommends "Avoid using [EEPROM]
address 0 for storage, unless you can guarantee that you will
not get a reset during EEPROM write." This is because an unexpected
reset during an EEPROM write will zero the EEPROM address registers.
Some boxes I have helped design have made use of non-volatile
memory for storage of fault information. At first, the technology
employed was NVRAM. More recently, we have used EEPROM. As you
noted in your article, the time available after a power-down indication
is often a factor in the design of the non-volatile storage software.
These days, one can get EEPROM having write cycles measured in
microseconds, and lifetimes of more than a million writes. It
has not always been thus. In our early use of EEPROM, we had to
cope with its limited write-cycle capability, and lengthy write
Since our interest is primarily in fault data, we generally write
it only when a fault is detected. Sometimes, there are many of
these computed in a single computation "frame". More often, the
box goes for days, weeks, or longer between faults. In any event,
the required 30+ year service life of the box dictates some provision
be made for limiting the number of writes to a given EEPROM address
when a fault is recorded. This means, for example, that storage
area pointers, or flags such as your "best" flag, must be distributed
over several different addresses. Likewise, operating hour information,
power-up counts, and other frequently-written data are arranged
to occupy several bytes.
As you suggest, each fault record has its own checksum. In fact,
it has several--one for each of the fields. Some fields actually
use "checksums" that permit bit-error correction, though the error
correction capability has never been used as far as I know. (These
Hamming codes are easier to compute than CRCs and you get the
error correction capability for free.) Our "current record" identification
and power-up count fields use a "traveling indicator" scheme.
Our fault memory stores information about the most recent 64
"equipment cycles." A corresponding block of 64 words is set aside
for pointers to the "current equipment cycle" data. As each equipment
cycle pointer is written, a "current record" indicator in the
pointer word is "toggled".
Larry D. Morris
There is a fourth consideration in planning when to store non
volatile data, and that is the lifetime write ability of the hardware.
There are some EEPROM technologies that have unlimited read capabilities
but a limited number of writes such as 100,000 or 1,000,000. Writing
once per minute will render the EEPROM useless in 2 years for
a part with 1,000,000 writes, assuming round the clock operation.
If your hardware uses such a limited write cycle device, some
checking of the expected usage and lifetime of the device and
a little arithmetic is in order when designing the non volatile
Thanks for some good columns. You have a knack for summing up
all the issues. Your columns could have saved me some grief if
I'd read them at the beginning of some of my designs.
Clarity Visual Systems
I just read your June column. I think you did a nice job of summarizing
many of the issues and methods involved with storing data in a
non-volatile manner. I have faced many of these myself.
One thing I did not see mentioned is the issue of wearing-out
memory by writing to it too often. Most EEPROM and Flash devices
are limited to 10,000, 100,000, or 1,000,000 write cycles. This
must be considered in the context of the intended life of a product
to determine the maximum allowable update rate. At my company,
we create products that are intended to last for 30 years, so
this is a significant consideration. We've come-up with a handful
of techniques for dealing with data that needs to be stored more
often than the write-cycle limit would allow, primarily be spreading
the storage of such data over multiple memory locations.
I look forward to your next column regarding maintaining non-volatile
data through firmware upgrades. This is another issue I have dealt
with, but have not been completely satisfied with the methods
we used. I hope I will find some new ideas in your article.
Schweitzer Engineering Laboratories, Inc.