Go Down

Topic: EEPROM Life Expectancy? (Read 21076 times) previous topic - next topic

captainhooyah

So I just read this in the EEPROM Tutorial:
Quote

Note:
An EEPROM write takes 3.3 ms to complete. The EEPROM memory has a specified life of 100,000 write/erase cycles, so you may need to be careful about how often you write to it.


Which made me wonder... Does the place (Flash Memory) where the Arduino Program is stored have this same issue?  I realize that 100,000 is a lot of times, but I have a project that stores calibration data in the EEP ROM. 
Eventually it will fail?
Will only the memory adresses I write to frequently fail?  Or will the whole thing fail?

Grumpy_Mike

Quote
Does the place (Flash Memory) where the Arduino Program is stored have this same issue?

Yes but is is a much lower limit than the EEPROM. It is about 10,000 if you are lucky.

Quote
Will only the memory adresses I write to frequently fail?

Yes

captainhooyah

Thanks Mike. 

I just read this somewhere else too.

Quote

There is one limitation to take heed of - the number of times we can read or write to the EEPROM. According to the manufacturer Atmel, the EEPROM is good for 100,000 read/write cycles (see the data sheet). One would suspect this to be a conservative estimate, however you should plan accordingly. [font=Verdana]*Update* After some experimentation, the life proved to be a lot longer…[/font]


Quote

Quote
Will only the memory adresses I write to frequently fail?
     -Yes


Not that I would do this... I'd say 100,000 calibrations would warrant a replacement arduino, but theroretically if you wanted to do it: Say you were only using a couple bytes of the EEPROM. You could also include a counter that incremented and stored to EEPROM every time you wrote to EEPROM.  Every time you wrote to EEPROM first your program would check against that counter, and after 990,000 writes to an address you could have your code automatically change the memory address and get more life out of the EEPROM.

Grumpy_Mike

Yes this is a well know technique known as ware levelling, they use in in SD cards as well.

john1993


Yes this is a well know technique known as ware levelling


wear leveling is indeed a popular method but captains description isnt usually the most common way. accepted practice is to allocate an area of ee and use a different location every time with a terminator.

although atmel specs 100,000 writes for ee and 10,000 for flash, in testing a few dozen chips from different lots to destruction, i found the typical max to be about 10x that. and normally the location being written is not the only one to fail. usually the entire row that byte resides in becomes unreliable. this block size varies depending on part.

rarely is it possible to wear out ee unless you create a program just for that purpose. dozens of players here and on other forums like freaks express concern but when calculations are done it often turns out it will take many decades. in some cases centuries.

Grumpy_Mike

Quote
although atmel specs 100,000 writes for ee and 10,000 for flash, in testing a few dozen chips from different lots to destruction, i found the typical max to be about 10x that. and normally the location being written is not

Well back in 2002 I was looking at flash memory for set top boxes. The Atmel spec was 10,000 but when we tested about 100, we found that some would only last 80 erase cycles and about 10% was under 200 cycles.
It is often program's that just treat flash like ram and do not consider its write limitations that run into trouble. In a loop you can trash EEPROM in less than ten minuites.

Paul__B


The Atmel spec was 10,000 but when we tested about 100, we found that some would only last 80 erase cycles and about 10% was under 200 cycles.


You weren't by chance using multiple byte writes to a region rather than block writes?

john1993

#7
Sep 17, 2013, 04:46 pm Last Edit: Sep 17, 2013, 04:50 pm by john1993 Reason: 1
tested about 100, we found that some would only last 80 erase cycles and about 10% was under 200 cycles.


im often puzzled by some of the radically differing experiences here. we dont know all your details but i suspect if others had similar results or it was reproduceable then would be front page news. and after legal battles the atmel name would probably be attached to some hole in the wall startup by now. or simply gone forever.

aside from relatively small samples involved in my destructive testing there have been many jobs where flash instead of ee was used for logging. for example one of my clients product few years back used flash to record gps info. several thousand units are out in the field at this point and some have reaches what i estimate to be about the half million cycle point with no failures of that type yet. as least none of the returns ive been asked to evaluate. the client companies warranty has long expired but i suspect most of those chips are still chugging along.

ps: you are right about erase being the real issue, not programming. you can write to the chip many times w/o penalty. some algorithms make use of this to reduce wear. ill also mention its very difficult to test flash failure because even after damage occurs you can still write successfully. its only by power cycling every time that the defects become apparent. i had to abandon flash testing early for this reason. ee behaves quite differently in this respect.


Grumpy_Mike

Quote
You weren't by chance using multiple byte writes to a region rather than block writes?

I don't actually know because the actual writing was being done by low level software that was written and controlled by Canal+. They specified the number of write cycles needed and we just called their low level routines.

Quote
but i suspect if others had similar results or it was reproducible then would be front page news.

Well no.
This was 2002 and I suspect that their design has changed since then. Also it was a separate flash chip. At the time these chips were being used by Motorola in their mobile phones in eye watering numbers and the number of upgrades done to the software was limited. In truth the number of software upgrades to the set top box never reached double figures but there was the spec that had to be met no mater how ridiculous it was. Also Atmel never actually quoted a figure on these devices and were rather coy about it so there was nothing anyone could have done legally. We did have visits and conference calls and discovered that the did as a factory check at chip level was to program all ones into the chip and test that all cells were one and the erase the chip and test all cells were zero. We were not very impressed with this to say the least. In fact this experience kept me away from the Arduino project for a couple of years.

Quote
you can write to the chip many times w/o penalty

Yes but you are limited to 8 meaningful writes because without an erase the write process is only one way, normally a one to a zero, but it could be the other way round depending on the way the flash cell is buffered.

Quote
as least none of the returns ive been asked to evaluate.

:) :) :)

fungus


Quote
you can write to the chip many times w/o penalty

Yes but you are limited to 8 meaningful writes because without an erase the write process is only one way, normally a one to a zero, but it could be the other way round depending on the way the flash cell is buffered.


I remember manually patching Z80 code on EPROMS with no eraser available. You had to look at the hex dump and figure out how to fix the program by only changing bits from 1 to 0. I didn't do it often, but I have done it.

Kids today...
Advanced Arduino

john1993


you are limited to 8 meaningful writes


true. but used in conjunction with the leveling algorithm described (resembling old ms fat method) can provide 8x improvement in lifetime for that operation. unfortunately its complicated by the fact that an entire row is erased and re-written even with one byte access. still an improvement though.
Atmel never actually quoted a figure on these devices and were rather coy about it


i wonder if anybody here remembers the "write only" ee of early step c t45 release. it only occured when lock bits were used so atmel didnt seem to recogize the urgency. yeah...right!

of course these are collectors items now like the 6502 with bad xor. ive seen the first go for $20 ea at auction and 2nd for hundreds. sitting on tubes of those t45 and owner of 3 first run 6502 im hoping the bottom dont fall out like with numismatic market.

tronixstuff


So I just read this in the EEPROM Tutorial:
Quote

Note:
An EEPROM write takes 3.3 ms to complete. The EEPROM memory has a specified life of 100,000 write/erase cycles, so you may need to be careful about how often you write to it.


Which made me wonder... Does the place (Flash Memory) where the Arduino Program is stored have this same issue?  I realize that 100,000 is a lot of times, but I have a project that stores calibration data in the EEP ROM. 
Eventually it will fail?


Yes - http://tronixstuff.com/2011/05/11/discovering-arduinos-internal-eeprom-lifespan/
A couple of Arduino tutorials at http://tronixstuff.com/tutorials - My Arduino book - http://nostarch.com/arduino. Please don't ask for help via direct message - use the forum!

john1993

Quote
1230163 cycles


over a million. this agrees almost exactly with the tests i ran. across different lots and even different parts numbers the results were very similar. atmel, like many other published specs, is being very conservative here. ie cya.

dc42


I remember manually patching Z80 code on EPROMS with no eraser available. You had to look at the hex dump and figure out how to fix the program by only changing bits from 1 to 0. I didn't do it often, but I have done it.

Kids today...


You were lucky to have EPROMS! [spoken with a Yorkshire accent]. When I built a Z80-based computer, EPROM programmers and erasers were too expensive for me to afford. I ended up crafting a 16-byte boot loader ROM out of a 74154 and some NAND gates. Honestly!
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Grumpy_Mike

Quote
I ended up crafting a 16-byte boot loader

You were lucky to have a boot loader, I had to toggle in the bytes into ram with switches.

Seriously though respect   :)

This was my computer in 1975
http://www.flickr.com/photos/33177304@N03/4578436531/

Go Up