AVR EEPROM Endurance

I was wondering if anyone has experience with EEPROM endurence on Atmel
AVR parts. I have a controller project that requires a real-time clock
that I originally planned to implement via a DS1320+supercap. However, I
recently found a prebuilt board that does 90% of what I want but does
not include a battery/cap backup RTC.

I can use one of the AVR timers to generate an accurate clock while it
has power. The question is what to do about power failures. My thought
was that at midnight I would write the current date to EEPROM and then
once per minute I would write one byte of EEPROM data that essentially
indicated the current minute.

Whenever the part gets powered up, I can read the current date from
EEPROM and then count the number of "minute flags" to calc the time.
Obviously this scheme "leaks" time when power is unavailable but that is
acceptable for my application (because the part also knows that power
was lost and can operate with that slightly skewed time until an
operator corrects it).

EEPROM endurance for the ATMEGA128 is listed at 100K erase/write cycles.
The scheme outlined above uses approximately 4+1440 bytes with each byte
being written once per day. So the question is whether the 100K
endurance applies at the per-byte level or overall. The answer obviously
represents a thousand fold difference in performance with the part
lasting either two months or 250+ years.

I could not find any good documentation from Atmel with a precise
definition of endurance. I did find an article from Microchip that
mentioned that EEPROM byte writes tend to be harder on parts than
page/bulk due to current issues related to the internal charge pump used
to write the EEPROM.

Anyone know enough about these parts to offer some guidance? Thanks.

--
Greg Schaefer (teamvraz@com_REM0VE_cast.net)

Greg Schaefer wrote:
> I was wondering if anyone has experience with EEPROM endurence on Atmel
> AVR parts. I have a controller project that requires a real-time clock
> that I originally planned to implement via a DS1320+supercap. However, I
> recently found a prebuilt board that does 90% of what I want but does
> not include a battery/cap backup RTC.
> 
> I can use one of the AVR timers to generate an accurate clock while it
> has power. The question is what to do about power failures. My thought
> was that at midnight I would write the current date to EEPROM and then
> once per minute I would write one byte of EEPROM data that essentially
> indicated the current minute.
> 
> Whenever the part gets powered up, I can read the current date from
> EEPROM and then count the number of "minute flags" to calc the time.
> Obviously this scheme "leaks" time when power is unavailable but that is
> acceptable for my application (because the part also knows that power
> was lost and can operate with that slightly skewed time until an
> operator corrects it).
> 
> EEPROM endurance for the ATMEGA128 is listed at 100K erase/write cycles.
> The scheme outlined above uses approximately 4+1440 bytes with each byte
> being written once per day. So the question is whether the 100K
> endurance applies at the per-byte level or overall. The answer obviously
> represents a thousand fold difference in performance with the part
> lasting either two months or 250+ years.
> 
> I could not find any good documentation from Atmel with a precise
> definition of endurance. I did find an article from Microchip that
> mentioned that EEPROM byte writes tend to be harder on parts than
> page/bulk due to current issues related to the internal charge pump used
> to write the EEPROM.
> 
> Anyone know enough about these parts to offer some guidance? Thanks.
> 
> --
> Greg Schaefer (teamvraz@com_REM0VE_cast.net)

I had a similar problem, and I decided against using the EEPROM.

Instead, I'm using a Ramtron ferroelectric RAM, which is specified
for over 10^9 writes <http://www.ramtron.com/>.

HTH

Tauno Voipio
tauno voipio @ iki fi

In message <J0xmc.482$OH1.402@read3.inet.fi>, Tauno Voipio
<tauno.voipio@iki.fi.NOSPAM.invalid> said...

> Greg Schaefer wrote:
>> I was wondering if anyone has experience with EEPROM endurence on Atmel
>> AVR parts. I have a controller project that requires a real-time clock
>> that I originally planned to implement via a DS1320+supercap. However, I
>> recently found a prebuilt board that does 90% of what I want but does
>> not include a battery/cap backup RTC.
>>
>> I can use one of the AVR timers to generate an accurate clock while it
>> has power. The question is what to do about power failures. My thought
>> was that at midnight I would write the current date to EEPROM and then
>> once per minute I would write one byte of EEPROM data that essentially
>> indicated the current minute.
>>
>> Whenever the part gets powered up, I can read the current date from
>> EEPROM and then count the number of "minute flags" to calc the time.
>> Obviously this scheme "leaks" time when power is unavailable but that is
>> acceptable for my application (because the part also knows that power
>> was lost and can operate with that slightly skewed time until an
>> operator corrects it).
>>
>> EEPROM endurance for the ATMEGA128 is listed at 100K erase/write cycles.
>> The scheme outlined above uses approximately 4+1440 bytes with each byte
>> being written once per day. So the question is whether the 100K
>> endurance applies at the per-byte level or overall. The answer obviously
>> represents a thousand fold difference in performance with the part
>> lasting either two months or 250+ years.
>>
>> I could not find any good documentation from Atmel with a precise
>> definition of endurance. I did find an article from Microchip that
>> mentioned that EEPROM byte writes tend to be harder on parts than
>> page/bulk due to current issues related to the internal charge pump used
>> to write the EEPROM.
>>
>> Anyone know enough about these parts to offer some guidance? Thanks.
>>
>> --
>> Greg Schaefer (teamvraz@com_REM0VE_cast.net)
>
> I had a similar problem, and I decided against using the EEPROM.
>
> Instead, I'm using a Ramtron ferroelectric RAM, which is specified
> for over 10^9 writes <http://www.ramtron.com/>.
>
> HTH
>
> Tauno Voipio
> tauno voipio @ iki fi
>

Thanks for the pointer, but in this situation I am specifially looking for a
software-only solution so I can leverage an existing product rather than
build my own. If I go the custom hardware route then an RTC with battery/cap
will provide superior performance over EEPROM/FRAM/etc since it won't loose
time during a power-outage.

--
Greg Schaefer (teamvraz@com_REM0VE_cast.net)

Greg Schaefer wrote:
<snip>
> EEPROM endurance for the ATMEGA128 is listed at 100K erase/write cycles.
> The scheme outlined above uses approximately 4+1440 bytes with each byte
> being written once per day. So the question is whether the 100K
> endurance applies at the per-byte level or overall. The answer obviously
> represents a thousand fold difference in performance with the part
> lasting either two months or 250+ years.

Data Spreading is certainly a good idea, as is some form
of failure, or bad-sector control.
You have described very wide data spreading, with low average
duty cycles.

Most wearout is erase related (most stressfull action).
Supplier data does not usually give details of bit handling
within a page, but safest assumption is lowest IQ/simplest
silicon. That means, within one page any write first erases
ALL page bytes, then replaces with the new values.
Chips that allow single byte writes might not imply single byte
erase - they can do this by read/modify/write of a page.

You could try this, and report back :
Set a device up in agressive wear-out mode :
* Take a single page, and write 55H/AAH alternating
   to half the bytes.
* Other bytes are 0FFH, except every 500
   cycles,do a FF/55/AA/FF cycle.
* Repeat over more Pages, will give wider stats base, but will
   take longer to reach counts.

Keep a verify failure count, and log in the other EEcells.
  Run at MAX cycle rate (polling) for some days.
This will show
-  bit failure patterns {expect single bit failures ?)
-  Do the low-cycle bytes in the page have lower failure rate ?

This will give a first data point, enough to start your design.
You could also then expand the test, to lower/widen the write-rate,
and it may be that a recovery time between cycles gives more
endurance. This is closer to real application, but now results
will take weeks. - still good to leave one in the corner...
-jg

In message <Tdzmc.415$FN.40500@news02.tsnz.net>, Jim Granville
<no.spam@designtools.co.nz> said...

> Greg Schaefer wrote:
> <snip>
>> EEPROM endurance for the ATMEGA128 is listed at 100K erase/write cycles.
>> The scheme outlined above uses approximately 4+1440 bytes with each byte
>> being written once per day. So the question is whether the 100K
>> endurance applies at the per-byte level or overall. The answer obviously
>> represents a thousand fold difference in performance with the part
>> lasting either two months or 250+ years.
>
> Data Spreading is certainly a good idea, as is some form
> of failure, or bad-sector control.
> You have described very wide data spreading, with low average
> duty cycles.
>
> Most wearout is erase related (most stressfull action).
> Supplier data does not usually give details of bit handling
> within a page, but safest assumption is lowest IQ/simplest
> silicon. That means, within one page any write first erases
> ALL page bytes, then replaces with the new values.
> Chips that allow single byte writes might not imply single byte
> erase - they can do this by read/modify/write of a page.
>
> <snip>

Thanks for the feedback. Your point about byte mode potentially being
implemented as read + page_erase + write is something I had not considered.
The page size on the ATMEGA128 is 8 bytes and I could certainly spread the
1500 bytes out using an every-other scheme to maximize distribution. Assuming
that the 100K endurance rating was page based, that would still be 50+ years
of operation which is well within my requirements.

This is actually for a hobby/home project where I am only going to be
building 3-4 controllers so I was hoping someone might have some existing
experience I could leverage rather than qualify the part myself (which I
would certainly do if this was any kind of commercial application). Because
the ATMEGA128 is TQFP and I don't have any around (I have older 8515's but
using a different part defeats the purpose), the amount of effort to put
something together for testing would come close to just building the real
controller.

Since this isn't a mission critical application and the worst case scenerio
is coming home and having mad cats pelt me with with warm beer (the
controllers are for my cat feeders and keg fridge), the best option might be
to build one with maximum EEPROM distribution and see what happens over time.

--
Greg Schaefer (teamvraz@com_REM0VE_cast.net)

Greg Schaefer wrote:
<snip>
> Since this isn't a mission critical application and the worst case scenerio
> is coming home and having mad cats pelt me with with warm beer (the
> controllers are for my cat feeders and keg fridge), 

Sounds 'mission critical' to me!! - Heck, if they are the wife's cats 
the consequences escalate to the unthinkable.... :)
..and as for the warm beer.....

 > the best option might be
 > to build one with maximum EEPROM distribution and see what happens 
over time.

yup.

> I could not find any good documentation from Atmel with a precise
> definition of endurance.

A. Email Atmel about your problem, they are very responsive and will
   give you more information than shown in the documentation (and
   usually include it in later revisions of the datasheets).

B. AFAIK the wear limit is byte-based.  Some AVRs have an EEPROM
   corruption problem with EEAR=0, which occurs when you reset the
   device while a write is in progress (reset sets EEAR=0, thus
   redirecting the erase operation from where it was meant to 0).
   At least the AVR parts that have this errata, do in fact work
   on a per-byte basis.

C. I have done more than 1M individual erase/write cycles on several
   ATmega103 parts without problem. The application was similar to
   yours (several ever-increasing up-counters), and used 32 bytes of
   EEPROM per counter instance.

Marc

In message <af3f5bb5.0405070151.60332038@posting.google.com>,
jetmarc@hotmail.com (jetmarc) said...

>> I could not find any good documentation from Atmel with a precise
>> definition of endurance.
>
> A. Email Atmel about your problem, they are very responsive and will
>    give you more information than shown in the documentation (and
>    usually include it in later revisions of the datasheets).
>
> B. AFAIK the wear limit is byte-based.  Some AVRs have an EEPROM
>    corruption problem with EEAR=0, which occurs when you reset the
>    device while a write is in progress (reset sets EEAR=0, thus
>    redirecting the erase operation from where it was meant to 0).
>    At least the AVR parts that have this errata, do in fact work
>    on a per-byte basis.
>
> C. I have done more than 1M individual erase/write cycles on several
>    ATmega103 parts without problem. The application was similar to
>    yours (several ever-increasing up-counters), and used 32 bytes of
>    EEPROM per counter instance.
>
> Marc

Great feedback. Point "B" in particular was something that I had not
considered. I don't see it mentioned in the mega128 errata, but its
certainly easy enough to avoid EEPROM page zero. Your success with high
erase/write counts in a similar approach also increases my confidence
this is likely to work.

I will drop a note to Atmel support to see what they say. The time
savings of using an existing design rather than building custom (even
if its not 100% what I need) is very compelling since I can do the
software side much faster than the hardware. Thanks,

--
Greg Schaefer // teamvraz@com_REM0VE_cast.net

In article <af3f5bb5.0405070151.60332038@posting.google.com>,
jetmarc <jetmarc@hotmail.com> wrote:
>B. AFAIK the wear limit is byte-based.  Some AVRs have an EEPROM

That is my understanding as well.

In particular, look at the AVR101 application note, on high-endurance
EEPROM usage.  It makes it fairly clear that the endurance is
per-location.