>> Each of my 8 records includes a 16 bit CRC.
>Using this CRC test technique, if you start to have a bad eeprom
address due excessive use  <snip>

>Thats the whole point of the CRC.  If I find a record with a bad CRC,
I don't use ANY portion of that record, including the sequence number.
I find the newest record out of those with data I can trust.

At the point when you store, you do a check on E2PROM and storage
integrity by ensuring byte-by-byte the block of written record is
correct, this is better than CRC check.  At this point, CRC do not
serve a purpose here.  Am I right?

So CRC tries to detect E2PROM failure, in addition to ensuring data
integrity during transfer, after you have written.  Therefore this
block of data is lost when CRC fails.  But doing what you suggested
below might produce the same good result at the time when you write,
and your risk of loosing another block of record is very high.  I
would not assume the previous write has failed since it was proven
correct.  I would read the block of data again to rule out noise
during transfer, and mark off the that block right away.

>Once I have found the newest record, I'll try writing the record with
the bad CRC once more, assuming that the CRC was bad because a
previous write failed.  If the write fails again, that chunk of eeprom
is swapped out with one of the spares.

One question is how does E2PROM fail in max. wear-n-tear?  Does it
fail at the point of writing, or can it fail after a proper writing
has been done?  I need to refresh my memory.

Cheers,

Ling SM