How many writes can a 24LC256 take ?, let's find out !

G

g6ejd

Senior Member
In a way it is no surprise, or is it. The device is specified at 1M max. but to get to that and have a published specification there will be a tolerance and manufacturing processes improve over time as do designs. So maybe we are seeing a combination of factors.

The random writes cannot be predicted by the on-board EEPROM logic, so it must be working. Does this mean we can all start to use these beyond their design specification; I think not, well not and to be sure of the operation in all conditions, temp for example.
 
L

LeonR

Member
I may be talking rubbish here, but if you alternated between 00000000 and 11111111 (0 and 255) would this not have the same testing abilities as a random number? (Just trying to understand how the picaxe works a little better).
 
Buzby

Buzby

Senior Member
I used random to minimise any systemic effects that may be caused by any type of predictable data. Not at home now, wonder if it's still running?
 
G

Goeytex

Senior Member
You guys are having so much fun with this, that I decided to wear out EEPROM memory location 127 on a spare Picaxe 14M. I'll let you know the results.
 
premelec

premelec

Senior Member
I recall an endurance test run for months about 7 years ago [or more?] - I don't recall how it came out - other than no need to worry about wearing PICAXE out...
 
D

Dippy

Moderator
Well done Ec, I thought I remembered a similar interesting test - saved me searching.
The statistical sample size on ONE is certainly better than none ;)
 
Buzby

Buzby

Senior Member
At approx 00:30 this morning it reached a total of 24,000,000 !.

Unfortunately there were 18 fails, but I don't know when the first occurred, somewhere between 14 and 24 million.

As I'm typing this it's just had two more fails, so maybe we are at the limit.

The fault is bit 1 reading as 0 instead of 1.

I'll leave it running for the rest of the night.

Cheers,

Buzby
 
Buzby

Buzby

Senior Member
Count now at 32,000,000 and failures coming in thick and fast.

So, somewhere between 14M and 24M it started failing, and by 32M it's definitely had it.

What have we learned ?.
 
S

sages

Member
Buzby said:
Count now at 32,000,000 and failures coming in thick and fast.

So, somewhere between 14M and 24M it started failing, and by 32M it's definitely had it.

What have we learned ?.
Click to expand...
errr, you lost count somewhere between 14e6 and 24e6 :cool:
 
fernando_g

fernando_g

Senior Member
Buzby said:
Count now at 32,000,000 and failures coming in thick and fast.


What have we learned ?.
Click to expand...
That the science of failure predictions is either fascinating or utterly boring. I tend towards the former. I also find it fun to take components to their limits and watching them destruct.

I once put a small audio amp chip in an oven. Unfortunately, the smell of burning insulation had my wife terminating the experiment earlier.
Testing the circuit after it had cooled down, found that some electrolytic caps had degraded, the IC was fine!
 
Buzby

Buzby

Senior Member
fernando_g said:
... I once put a small audio amp chip in an oven. ...
Click to expand...
Try a CD in a microwave, smelly but spectacular !.

Anyway, it's at 36,000,000 now and failing frequently.

I'll leave it running for a few hours more, then switch to a different EEPROM cell.
It will be interesting to see if the failure affects more than the 'target' cell.
 
J

John West

Senior Member
I'm certain they conservatively rate the read/write failure point. It's very much like trying to stipulate at which mile (kilometer) an automobile will break down.

You could easily hit 50 to 100 million writes if you are operating in a relatively cool environment with lower applied voltage. But only with that chip. The next one may die at little more than the number of cycles specified in the datasheet.
 
B

BeanieBots

Moderator
I'm with John West.
Try it again at maximum Vcc and maximum temperature rating.
(ideally using at least 20 different batch numbers)
 
G

g6ejd

Senior Member
Thanks for this experiment/trial - as a consequence I am no-longer going to be as concerned / paranoid as I was in over-using EEPROM, it may fail early, but on balance the probability of this seems low.
 
Buzby

Buzby

Senior Member
Due to other events, I've had to leave this test running for four days solid. ( At 200 writes per second I'll let you work out how many that was !.)

The test code used 'hi2cout 0, (x)' to write millions of times to EEPROM location '0'. This location failed somewhere after 14 million.

Today I just did a quick write/read test on all the other locations in the EEPROM. The results show location 0 to 31 are broken, but 32 to 32767 look OK.

So this means either :

The EEPROM itself failed a whole page, even though only one location was being written.
- or -
The PICAXE was doing 'page writes' instead of 'byte writes'.

I'll set the rig up for another test, this time to a single mid-page location, and see what that produces.

And a question for Goeytex, how's your 14M doing ?

Cheers,

Buzby
 
G

Goeytex

Senior Member
I shut the 14M down at 3,100,000 writes with no errors because I needed that breadboard for a small temporary project. I'll crank it back up this AM and let it go ....
 
A

Armp

Senior Member
Buzby said:
Today I just did a quick write/read test on all the other locations in the EEPROM. The results show location 0 to 31 are broken, but 32 to 32767 look OK.

So this means either :

The EEPROM itself failed a whole page, even though only one location was being written.
- or -
The PICAXE was doing 'page writes' instead of 'byte writes'.
Click to expand...
Page size is 64 bytes....
 
hippy

hippy

Technical Support
Staff member
Buzby said:
The EEPROM itself failed a whole page, even though only one location was being written.
- or -
The PICAXE was doing 'page writes' instead of 'byte writes'.
Click to expand...
Entirely feasible and even likely. The write may update a copy of the page being edited, then at the end put the entire page back to the EEPROM memory. So even if only a single byte is updated the entire page may be erased then written.

At the internal hardware level there may be no such thing as a byte write.

The 24LC256 has a 64 byte page from the I2C master's perspective but the internal EEPROM hardware page size does not have to be the same.

For more complicated non-volatile devices with 'wear levelling' a page may not even be written in the same place every time, pages may be moved around behind the scenes. When one page fails it would be likely that all other pages will also be close to failing.

There's no guarantee that all pages are even equal. Pages more likely to be written ( those which would hold a FAT for a file system ) may have higher life than others or be the limited few with wear levelling.

Such complexity would seem unlikely for a humble I2C EEPROM but only Microchip probably knows exactly what their chips actually do.
 
A

Armp

Senior Member
From Microchips "Total Endurance™ v5.00 Quick Start Guide"

Page Architecture
Microchip’s new EEPROM architecture is page based and forces the entire page to
undergo a write cycle even when individual bytes are addressed. This design supports
pseudo byte writes (or multiple bytes of less than a full page) so the new devices can
be used as a replacement for older devices with no code changes required. All writes
to a page now refresh all of the bytes of the page whether the specific bytes are
addressed or not.
With the new page architecture, the entire page is read into latches at the beginning of
the Write command. As data is received, it is loaded into the appropriate latches to
replace the old data. At the end of the Write command, the entire page is written using
the data in the latches. This is essentially a read-modify-write operation on the entire
page.
Because the entire page endures a write cycle during each write operation, endurance
is specified per page.
Click to expand...
 
W

westaust55

Moderator
From the 24LC1025 EEPROM datasheet:
When doing a write of less than 128 bytes the data in the rest of the page is
refreshed along with the data bytes being written. This will force the entire page to
endure a write cycle, for this reason endurance is specified per page.
Click to expand...
24LC512 and 25A51 datasheets has the same note.
 
Buzby

Buzby

Senior Member
The corresponding datasheets for 24LC64 and 24LC256 show these devices have 64 byte pages.

This doesn't explain why 32 of my bytes have failed, unless as hippy says, there is more going on 'under the hood' that the datasheet states.

Next test is started. Writing to 1043, ie 1028 + 15, which is somewhere in the middle of a 32 byte page ( or a quarter of the way through a 64 byte page ).

Give it some time and I'll post the results.

Cheers,

Buzby
 
hippy

hippy

Technical Support
Staff member
Buzby said:
This doesn't explain why 32 of my bytes have failed, unless as hippy says, there is more going on 'under the hood' that the datasheet states.
Click to expand...
It could be that the page is 64 bytes, all 64 bytes are written each time, but is wired or interacts such that the 32 which aren't all $FF wear more than the 32 bytes which are all $FF.

We know that a 32 byte area has been damaged but we don't know how worn any other areas may be. We cannot say for certain that all are unaffected.
 
Buzby

Buzby

Senior Member
hippy said:
...We know that a 32 byte area has been damaged but we don't know how worn any other areas may be. We cannot say for certain that all are unaffected.
Click to expand...
Fully agree !. This chip is not going to be used for anything other than this test.

I determined that 32 bytes were damaged by doing a simple 'hi2cout addr, (255)' for all 32768 locations, and only the first 32 did not read back as 255.
Repeated with a random byte, same results.

The second test is running now, currently at 1.6M, so probably get result tomorrow.
 
P

Puuhaaja

Senior Member
Cool test! few month ago I also planned to do similar test but I ended up to do speed test for Picaxe. I tested how many codelines Picaxe perform in one second with different mhz freqvencies. I also tested different kind of code lines and noticed that some codes need more time than others.
 
Buzby

Buzby

Senior Member
Puuhaaja said:
...I also tested different kind of code lines and noticed that some codes need more time than others.
Click to expand...
Yep !.

Different codes take different times, that's not a surprise.

But did you test different variables ?. e.g. B0 is faster than B55.

The tokeniser in PE is optimised for size, less 'bits per value' takes less space, so every PICAXE has a tricky interpreter which has to convert, e.g. 2 bits into 8 bits ( or sometimes 16 bits.)

And it gets more tricky still !.

The 'x +1 ' in bit of code such as :
x = x + 1
y = y + 1

might run faster, or slower, than in a bit of code like this :
y = y + 1
x = x + 1

It depends where the tokenised values of x and y are located in the program memory.

I think Westie and hippy did some in depth studies of this.

Anyway, back to the plot, 24LC245 addr 1043 started failing after 1 day 5 hours of work. At 200 writes per second I think that's about 21,000,000 writes

Further details tomorrow, I'm off to bed !.

G'night,

Buzby
 
O

oracacle

Senior Member
is there any chance of sub-zero testing to seeing of low tempuratures will prelong the life the EEPROM. we all know that silicon like to run cooler and i ma pretty suer they will run to -50*c, would be interesting to seeing if it has a significant effect being in the freezer for several days
 
A

Armp

Senior Member
oracacle said:
is there any chance of sub-zero testing to seeing of low tempuratures will prelong the life the EEPROM. we all know that silicon like to run cooler and i ma pretty suer they will run to -50*c, would be interesting to seeing if it has a significant effect being in the freezer for several days
Click to expand...
The Microchip EEPROM Endurance Tutorial AN1019 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en025550 has tables for the effect of Temperature and Voltage on EEPROM endurance.

View attachment 14449View attachment 14450

BTW - The devices are spec'd for !M cycles at Vccmax = 5.5V, Tempmax=125C.

For maximum 'life' run them cool, and at low voltage.

AT -40C you'd expect to get ~4X improvement over room temp.
 
P

Puuhaaja

Senior Member
But did you test different variables ?. e.g. B0 is faster than B55.
Click to expand...
No. I used variables only in the end of program code so that after performing whole program 10 000 times led would flash and I could measure the time. It was a bit exciting to do different kind of code tests.
 
J

John West

Senior Member
Interesting stuff, especially the temperature info. I used to program UVEPROM's, then put them in the freezer overnight so they were a few degrees below their minimum rated operating temperature, (zero C.) Then I'd pull them out, plug them in and do a read. If all the data read correctly, I figured my home-made, and home designed, programmer was working acceptably.

In practice, the EPROM data has been retained for over 15 years, so far. But there's no telling if I "over-cooked" the EPROM's and reduced the number of times they can be reprogrammed. Those old style memory chips are fussy little beasties.
 
P

phillid

Member
This is great research (can we even call it that? ;))!! A long while back now, I got my hands on a couple of these I2C EEPROMs and once my father mentioned 1,000,000 writes. I was holding back from doing anything that was heavy on writes - these things were expensive for a boy on less than pocket money!
Nowadays the price doesn't matter, but it's still good to know just how under-spec'ed they can be!

I've got an old Z80 embedded system board with a 1980s era 512-byte EEPROM on it... it would've cost $$$ in its day, but it's sad to think that I'm thinking of testing its limits... ;)
 
D

Dippy

Moderator
It has been a very useful demonstration, as was the other one someone did a while back.

You'll find that manufacturers have based their specs very much on the side of caution and their own testing methods make good reading.
It would also be interesting to see some real-life tests on the variety of K series PICs where the endurance claims are 'only' 100,000 writes.

And, obviously, we must be a little careful with basing our project endurance based on a sample of 1 (one) under one set of conditions. Lies, damned lies and statistics... who was it that said that?
 
D

Dippy

Moderator
Aha, well done.

Some else said "What's the probablity of being able to say the word 'statistics' after drinking a bottle of Port?".
 
S

SAborn

Senior Member
"What's the probablity of being able to say the word 'statistics' after drinking a bottle of Port?".
Click to expand...
Slim chance i would say.
One might think you have tested this theory, but not yet published a result on it, with more R&D required.:D
 
You must log in or register to reply here.
Top