1. Home
  2. Embedded Programming
  3. AVR EEPROM Endurance

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)

Reply to
Greg Schaefer
Loading thread data ...

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 .

HTH

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

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)

Reply to
Greg Schaefer

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

Reply to
Jim Granville

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)

Reply to
Greg Schaefer

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

yup.

Reply to
Jim Granville

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

Reply to
jetmarc

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

Reply to
Greg Schaefer

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.

Reply to
Terran Melconian

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.