EEPROM Life Expectancy?

So I just read this in the EEPROM Tutorial:

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?

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.

Will only the memory adresses I write to frequently fail?

Yes

Thanks Mike.

I just read this somewhere else too.

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. Update After some experimentation, the life proved to be a lot longer…

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.

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

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

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.

Grumpy_Mike: 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?

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

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.

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.

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.

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

:) :) :)

Grumpy_Mike:

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

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

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

captainhooyah: So I just read this in the EEPROM Tutorial:

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/

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.

fungus: 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!

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/

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

Nice! I guess you used the switches to set memory contents directly, in traditional minicomputer fashion? I used the bootloader to read a single centre-off toggle switch. Entering each byte serially, after a number of attempts, I managed to enter a simple O/S and got it to write itself to tape. The tape used a 3-frequency self-clocking encoding, which allowed me to use the same hard-wired bootloader to read the tape.

I don’t have a photo of mine, and most of the bits got thrown away when I moved house several years ago. It was built on Eurocards wired using Verowire, mounted in a rack with a bus connecting the cards. AFAIR I had a card for the CPU, a card for 1K of static RAM, and a card for I/O. Eventually, also a 4K dynamic RAM card, a floppy disk controller card, and a card for driving an ICL line printer (the sort with a rotating barrel, very noisy, picked up from a scrap dealer in Reading).

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

Using octal!

dc42: Nice! I guess you used the switches to set memory contents directly, in traditional minicomputer fashion? I used the bootloader to read a single centre-off toggle switch. Entering each byte serially, after a number of attempts, I managed to enter a simple O/S and got it to write itself to tape. The tape used a 3-frequency self-clocking encoding, which allowed me to use the same hard-wired bootloader to read the tape.

I don't have a photo of mine, and most of the bits got thrown away when I moved house several years ago. It was built on Eurocards wired using Verowire, mounted in a rack with a bus connecting the cards. AFAIR I had a card for the CPU, a card for 1K of static RAM, and a card for I/O. Eventually, also a 4K dynamic RAM card, a floppy disk controller card, and a card for driving an ICL line printer (the sort with a rotating barrel, very noisy, picked up from a scrap dealer in Reading).

YEAH? Well I used Windows ME. For like a year. drops mic

XD

Paul__B:
Using octal!

Yep no one used hex in those days because the PDP computers had a 12 bit bus and so that fitted into four octal digits.
That computer used what was called crazy octal one digit of two bits and two digits of three bits. It made a lot more sense at the time.

I guess you used the switches to set memory contents directly, in traditional minicomputer fashion?

Yes the data was set with those switches and the address was provided by a counter. There was a push button to transfer the data switches into the address counter which was also clocked by the write push button. Basically the memory was programmed like this, then the three position rotary switch over to read to verify it, finally it was switched over to run where a bunch of data select chips switched the memory’s address lines over from the address counter to the processor.

I had never even seen a PDP8/12 before so it was all worked out from scratch.