Seeking authoritative reference for 100K EEPROM write limit

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know the datasheets for ATMegas state there's a 100K limit on EEPROM writes, and there are many mentions on the forum that this limit applies to individual bytes within the EEPROM array, not the entire array (i.e. you can write every byte 100K times). I've not been able to find, however, and authoritative reference claiming the limit is byte-based and not array-based. Can someone point me to one? Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the price of a $3 AVR you could write a loc, read it back, increment a count. Repeat until fail. Run test at room temp, run again on another avr at hi temp. Report back which way gives more writes.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the price of a $3 AVR you could write a loc, read it back, increment a count. Repeat until fail. Run test at room temp, run again on another avr at hi temp. Report back which way gives more writes. At 5ms per write 100K writes should take 500 sec. Hurry! We cant wait!

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What's the difference between it being byte-based versus array-based? Rewriting each individual byte 100K times and rewriting the array 100K times is the same thing at the byte level. Are you asking whether the 100K limit means that you can only write 100K bytes total to the array, e.g. rewrite one byte 100K times, or rewrite 1000 bytes 100 times?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I was wondering about the eeprom wearing level.
I did small programm. Just write, read it back, compare, increment for a single cell.
I ran it for few hours. I did about 1,000,000 successfull rewrites. Could not failed the eeprom.

Anyway I did some eeprom manager. change the location each time the uC boots.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the data sheet guarantees a minimum 100k writes to a single byte location, I would not be surprised by a typical 500k success rate. 1M is not that far from 'typical' in the realm of statistics.

I would follow wise Uncle Bob's advice. Write each location until failure. Log the best and worst case locations.

Repeat for new specimens in a freezer and oven.

Yes, I would be "interested" in your results.
No, I can't remember anyone reporting the results for a specimen AVR.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This topic comes up about once every 6 months and on prior occasions people have run the experiment and written their AVR to the point of destruction. I think it's found (search for the threads) that rather than 100,000 it actually takes a few million to destroy locations in the memory. But I guess Atmel's quoted 100,000 is both conservative and quoted for worst case conditions of temperature and voltage so I don't think you could design something commercial on the basis of one experiment result.

The same (and other threads) have discussed whether this 100,000 limit applies byte-wise or if it is somehow related to a "page size". I lost consciousness before I remember getting to the answer for that one but I'm sure the threads will reveal all.

Quote:

No, I can't remember anyone reporting the results for a specimen AVR

I *think * it may have been "Brutte" who was one of the people who've done the experiment but don't hold me to that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got the "Sorry AVRfreaks is experiencing vertigo" dialog box while submitting that message. After a while everything seemed to wake up again, but the message had been submitted twice. I saw that on Startrek once, Kirk got lost in the transporter during a power glitch or something and two of him popped out on the other end.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I got the "Sorry AVRfreaks is experiencing vertigo" dialog box while submitting that message. After a while everything seemed to wake up again, but the message had been submitted twice. I saw that on Startrek once, Kirk got lost in the transporter during a power glitch or something and two of him popped out on the other end.

And we all thought you were testing how many times you could post the same message before the giant EEPROM that hosts AVR Freaks wore out...

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the giant EEPROM that hosts AVR Freaks

If only that were true. The core of Freaks actually looks like this:

(only the wiring isn't in such good condition ;-))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The same (and other threads) have discussed whether this 100,000 limit applies byte-wise or if it is somehow related to a "page size". I lost consciousness before I remember getting to the answer for that one but I'm sure the threads will reveal all.

I think that if you follow the links in this thread you will come across the info:
https://www.avrfreaks.net/index.p...
OP asked for: "authoritative reference for 100K EEPROM write limit". Us 'freaks will have only anecdotal evidence.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I *think * it may have been "Brutte"

I have never tried wearing-out memories. I was only interested in the endurance of 10k cycles of something.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

the giant EEPROM that hosts AVR Freaks

If only that were true. The core of Freaks actually looks like this:

(only the wiring isn't in such good condition ;-))

Isn't that the web server?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I got the "Sorry AVRfreaks is experiencing vertigo" dialog box while submitting that message. After a while everything seemed to wake up again, but the message had been submitted twice. I saw that on Startrek once, Kirk got lost in the transporter during a power glitch or something and two of him popped out on the other end.

Do not joke like this, please!
I had vertigo few years ago.
Same feeling like getting down from a whirligig, BUT you have this feeling for days!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps the eeprom would fail closer to the 100 thousand guarantee if you were running it at the extreme edges of the specifications like temperature or voltage. Or perhaps if you had gillions of them running at the edges of the specifications...

But no, there is no circuit that counts eeprom writes and disables it after the 100 thousandth write.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But no, there is no circuit that counts eeprom writes and disables it after the 100 thousandth write.

Judging by the 10,000 versus 100,000 erase limits in AVR I have a suspicion that the application flash is MLC Nand flash and the EEPROM is SLC Nand flash (or possibly eMLC). That would explain the ten-fold difference in endurance.

Either way flash generally works by holding a charge on a floating gate. When you erase a cell by applying the large reverse gate voltage the substrate of the floating gate oxidizes slightly until eventually it reaches the state in which the gloating gate is no longer isolated correctly and that bit can no longer hold a charge indicating stored data state.

As such I suppose you could say that there is a "circuit" in there that imposes the 100,000 limit - it's the isolation of the floating gate and it does change (degrade) over time. What's not certain is exactly how long it's going to last so it's not like there's a guarantee that it fully oxidises after 100,000 cycles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
This topic comes up about once every 6 months and on prior occasions people have run the experiment and written their AVR to the point of destruction.

The same (and other threads) have discussed whether this 100,000 limit applies byte-wise or if it is somehow related to a "page size".

I have done this test a few years ago, but I don't think I've reported the results here.
Anyway, I had the "page size" thought back then, and decided to test it once and for all. The "victim" was an AT90CAN32. The result was that there is NO page size involved in the EEPROM. Each byte write only wear on itself.
Each byte was writeable from 1.8 million to 4.5 million times, with an average of 2.8 million. I made the test in both room temperature and around 65-70 deg C, but didn't find any significant change in the lifetime.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great information - that finally nails that one then!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That just determines the point of immediate failure.

It might be useful to know how many times a byte can be written and still hold its value after some minimum length of time.

Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

That just determines the point of immediate failure.

It might be useful to know how many times a byte can be written and still hold its value after some minimum length of time.


Keeping in mind that OP asked for an "authoritative reference", then we need an infinite amount of AVRs, right?

But we know that people have gotten up to 8 million writes, so maybe not infinite but only 10 million AVRs.

Since we know that there is no paging involved then if we pick an AVR model with 1k of EEPROM, then we need only 10000 AVRs, with a different write count to each. (Oh, my! Then we would have only tested the results on >>one<< of the hundred or so AVR models. So we indeed need a million AVRs; actually more because many have less than 1k of EEPROM space.)

Now we need to examine each for retention after an infinite number of time intervals. Obviously impractical, so use discrete time intervals. Test each one each day?

So if Greg is looking for a 10-year retention number we'll have the result 10 years after the experiment is set up.

Given the enormity of the test setup outlined above, the tests would only be at a single Vcc level for the stress testing, a single Vcc level for the readback, and a single temperature?

[For anecdotal reference, follow the links I gave and some of the stress testers had gone back to it after some time and noted some results for "burnt out" bytes.]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Keeping in mind that OP asked for an "authoritative reference", then we need an infinite amount of AVRs, right?

Why would you think that? You know about statistics and sampling, right? Maybe you've confused "authoritative" with "exhaustive?"

In any case, determining the number of times you can write to the EEPROM before you are unable to read it back after a very short time interval probably does not tell you much about the 10 year retention. However, it doesn't follow that the only viable test to figure it out is your naive, brute force, ten year test program.

Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dalpilot wrote:
You know about statistics and sampling, right?
This series touches on the subject of electronic component reliability.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]