EEPROM endurance and pages

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

As a followup to this thread, I concocted a dirty test which aims at revealing the paged nature of EEPROM in AVRs.

It writes an alternating pattern of 55/AA into a certain EEPROM position in batches of 1000, and then reads back this position to find out wear and tear. It also writes this alternating pattern once per batch into neighbouring bytes and reads it back at the end of batch - that should reveal whether any paging is involved in rewriting the EEPROM. Results are printed through UART.

I am now running it on a "spare" ATM128. Currently, it runs batch #840, no, wait, #841, so it is well over the stated endurance limit, and it's still OK - but that's no surprise, nominal endurance certainly guarantees proper readback at temperature extremes etc. which I don't exercise, of course. One "batch" lasts around 9s (as one EEPROM write is nominally 8.5ms at the 'M128), so 1M writes happens in around 3 hours. I expect the first errors will occur within 10M writes, i.e. a couple of days' "work".

Other experimenters willing to kill an AVR of choice are welcome to try to adopt this snippet, of course.

Jan Waclawek

PS. #871 and counting...

Attachment(s): 

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

Interesting.
Let us know the results..
Also, since you seem to have a lot of time, could you try a flash killer experiment? i am more interested in that..

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

wek wrote:
Currently, it runs batch #840, no, wait, #841, so it is well over the stated endurance limit, and it's still OK
I would not call the ability of holding the data for a few ms a proper indication for being OK for a EEPROM cell. ;-)
Perhaps the isolation of the floating gates is already damaged, so the cells loose their content in a few years, or months, or days, or ...
But of course this doesn't make a difference for the actual purpose of your test.

Stefan Ernst

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

I did something similar a couple of months ago. I did that on an atmega168. I think I ran my tests 4 times (and therefore "killed" 8 pages). In all cases errors started showing up after 4M-5M writes.

Eugene

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

This whole exercise seems to me to be similar to the "can I overclock my AVR to xxx MHz?" -- you will determine the capabilities of one particular AVR under one particular set of conditions but you have no clue as to whether the next AVR (be it the same or different model, or even the same or different Fab batch) you try will be similar. Nor will you have a clue if one minor change in conditions will also change the results.

I assume that Atmel does not place limits on it's components for arbitrary or capricious reason. After all, if Atmel could spec the EEPROM as working for up to 8 M rewrite cycles, don't you think they would? It would be a competitive advantage in at least some market.

If you intend to know the EEPROM write cycle limit for some hobby venture, that's fine; rock on! But know that you are probably not learning all that can be known about the EEPROM rewrite cycle problem. And know that if you choose to violate that limit in a commercial product, and the commercial product fails, and the purchaser of your product sues you, don't go whining to Atmel. They've told you the limit; if you violate it, you're on your own.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Stu,

As I understand it the idea is not to determine endurance but the "page size".

To read some Atmel documentation you might believe that every single byte (because it appears individually writeable/eraeable) was effectively a separate "page". So if you write 100,001 times to location 37 then after the 100,000th write it may well become "dead" but locations 36 and 38 on either side would still be good for their own 100,000 writes each.

However other things have suggested that the EEPROM is really in "pages" (some have suggested 4 byte groups) so when you make a write to location 37 that involves some 0->1 bit transitions - that would require a cell erase - that what really happens is that a group of 4 (is it?) bytes are read to a buffer, the entire page (37th,38th,39th,40th?) are then erased and the other 3 bytes have their content written back. In which case repeated writes to 37 really "wear out" the entire page of 4 bytes (or however many).

Jan is trying to work out if it is 4 or some other value.

Cliff

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

I would be interested in knowing how many times the Flash memory can be written before it begins to fail.
The data sheet says at least 10,000 times and people here report that it can be done more.

A hot soldering iron destroyed one of the thin flex cable on my ICE200. I'm been doing 100+ reloads a day to the CPU with the ICE200 when developing a non-trivial application. Lots of test points set and cleared, along with many minor changes. With only 10000 rewrites to an individual AVR, the debug device will have to be exchanged every two months or so.
I suspect that people use a simulator more often when an ICE is not available. But it's awkward to simulate 100+ bytes loaded from an external source and then processed with the results displayed on an LCD screen. I believe that there are pseudo-LCD displays available for the AVRstudio simulator. Is one recommended over another? Do they work at all?

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

clawson wrote:

Jan is trying to work out if it is 4 or some other value.

The EEPROM page size is given in the data sheet. For example the XMega 128A1 is 32 bytes. The CAN64 is four bytes. The CAN64 part is where the issue first came up.

The real question is the value one (no page) or lager than one (page size), as the actual page sizes are known.

As I'm the one that started this controversy I'd like to see it put to rest one way or the other, preferably by some one at Atmel with definitive knowledge of the subject.

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

For Wek's Mega128 test chip the EEPROM Page Size is eight bytes, see table 125.
http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf

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

bpaddock wrote:
For Wek's Mega128 test chip the EEPROM Page Size is eight bytes, see table 125.
http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf

No, that says nothing about the real EEPROM architecture. It is a programming specification - the "page" there might simply refer to a buffer in the programming "machine".

The datasheets are contradictory in what they say about EEPROM, and given the level of competence of datasheet-writers at Atmel Norway, I simply doubt the support personnel who gave you that information is much more competent.

JW

(Had to abort at around #2600 i.e. 2M6 writes due to other things to do).

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

First results.

The permanently rewritten byte failed first time at around 7M2 writes. All the neighbouring bytes (having been written around 7k2 times by that time) are well.

I will repeat the experiment, but IMHO this, together with Eugene's findings, are quite a good proof of that EEPROM paging does not apply for the endurance, at least for the self-writing case. (I now believe "paging" applies only to parallel/JTAG programming).

And, of course, this is no proper endurance testing, just an attempt to find out the "paging" status, until somebody really knowledgeable at Atmel confirms.

JW

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

Did this once on a PSoC, which was rated at 50,000 cycles. It croaked at about 150,000, IIRC.

However they make specific reference to temperature in the datasheet - especially to low temperature. We did this at about 50deg, which is more likely the application temperature for that particular product.

Hmmm....

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

damien_d wrote:
We did this at about 50deg, which is more likely the application temperature for that particular product.

Hmmm....

Celsius or Fahrenheit? I would assume the former because of your location ... but for the benefit of our US "readers" ...

Cheers,

Ross

Ross McKenzie ValuSoft Melbourne Australia

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

valusoft wrote:
damien_d wrote:
We did this at about 50deg, which is more likely the application temperature for that particular product.

Hmmm....

Celsius or Fahrenheit? I would assume the former because of your location ... but for the benefit of our US "readers" ...

Cheers,

Ross

Oops... Celsius :)

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

Quote:

The permanently rewritten byte failed first time at around 7M2 writes. All the neighbouring bytes (having been written around 7k2 times by that time) are well.

Excuse me for asking, but what are these numbers? Is "7M2" 7200000 or 7200000000? I assume that 7k2 is 7200, is this correct?

Europeans and Americans use different ways of writing numbers. French use 'M' for both million (10^6) and billion (10^9). They have some way of telling the numbers apart, but I don't know how.

Also, Europeans and Americans use different ways to indicate the separation between whole number and fraction. Europeans use a comma for ten and a half "10,5", while Americans use a period for ten and a half "10.5". Decimal grouping in thousands is done with a period in Europe and with a comma in the Americas; 10^6 is 1,000,000 in the USA and 1.000.000 in Europe.

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

I'd assume that 'M' is for 'Mega', thus making "7M2" 7200000. 7200000000 would, with the same notation, be 7G2.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

The typical programming time on m128 appears to be 8.5ms. Reaching 7G2 would take (in years):

perl -e "print(8.5*7200000000/1000/3600/24/365);"
1.94063926940639
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Europeans use a comma for ten and a half "10,5", while Americans use a period for ten and a half "10.5". Decimal grouping in thousands is done with a period in Europe and with a comma in the Americas; 10^6 is 1,000,000 in the USA and 1.000.000 in Europe.

I think your use of "Europe" in there is a bit general!

I think the motive behind using the SI unit prefix as a decimal separator is to avoid the international misinterpretation of '.' and ','

The French may well use 1,333MHz while the British (and yanks) use 1.333MHz but if they all use 1M333 Hz then they'd all understand it as one and one third megaHertz

Cliff

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

I have to abort the experiment #1 now. The first byte has seen >22 million writes, failed to read back correctly for the first time at around write number 7.2 million. The rest of the would-be page has seen around 22 thousands of explicit writes. If there would be any page mechanism involved, they would most probably have failed by now, too.

Ergo, there are no EEPROM pages for internal writes. Draw your own conclusions.

For our US readers: mega, abbreviated as M, is an SI (international measurement units, uses metres and kilograms, used now everywhere except US) prefix meaning x1000000. I admit that using it in the middle of a number instead of the decimal sign, whatever is that, is a slight abuse, although not unseen in engineering practice. Also, our (continental european, French-influenced) notion of billion is different from the anglo-saxon practice; our billion is 1E12; and we have an additional expression for 1E9, milliard. This might potentially lead to some confusion; however, I have never seen milliard to be abbreviated as M (it's usually mld).

JW

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

So, experiment#2: rewrite a single EEPROM byte through ISP as many times as possible and see, whether it causes damage to neighbouring cells. The subject under test is an ATMega8. The rest is the same as in experiment #1 - in fact, I recycled most of the previous program.

Up and running. Currently at #32 and counting.

JW

PS1. The damaged byte from experiment#1 is now stuck at 0x00. I wonder what would be the content if I would stop the experiment at the first encounter of mismatch. Experiment #3, maybe?

PS2. Discovered a flaw in experiment #1 - IMHO not substantial to the findings, nevertheless it did not do exactly what I "specified" in the first post of this thread. Could be found by comparing the two .c files... Who's the first to spot it? ;-)

Attachment(s): 

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

Results for experiment #2!

The often-written byte failed in batch 4970(i.e. nearly 5M writes). Now it is at batch 5527, and still no traces of the neighbouring "rarely written" bytes failing.

Now also the content of failing byte is printed. It is read immediately after end of a 1000-writes batch, and it should read 0xAA. Roughly in half of the cases it reads correctly, and in the rest it reads 0x2A. I guess this means that bit 7 in that byte is "leaky" towards zero.

JW

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

Batch #8275, i.e. 8M+ writes. No marks of paging, the "not so often" written bytes exhibit no apparent "leak".

The often written byte now reads immediately after the batch of writes at random as 0x0A, 0x08, 0x02 or 0x00 - damage increased. It is enough to heat the chip up by a touch to see always 0x00 to be read - the charge leaking is clearly temperature dependent, as expected.

JW