How many writes can a 24LC256 take ?, let's find out !
- Thread starter Buzby
- Start date
hippy
Ex-Staff (retired)
It depends upon exactly what your test does; are you repeatedly writing one location or cycling through memory and what's your definition of "fails" ?
If hammering one memory location it could all be over within a couple of hours but I expect you will achieve better than that.
If hammering one memory location it could all be over within a couple of hours but I expect you will achieve better than that.
westaust55
Moderator
ten times the Microchip defined life for 24LC256 . . .This sounds interesting!
I'm going with 10,000,000 not sure why!
but certainly not to say it cannot last longer. The 10^6 wrie cycle life would be seen as a guaranteed minimum though you could have a task proving it failed before that in a warranty claim.
Nevertheless we await Buzby's EEPROM test outcome
However for the EEPROM in PIC chips (Across many datasheets):
westaust55
Moderator
as asked already,
are you writing to a single location or all loactions the same number of times.
Then coul see how long betfore one byte fails, how long before say 10 bytes fail (bit like how many "dead"/faulty pixels on an LCD screen) and how long before 10% fail.
are you writing to a single location or all loactions the same number of times.
Then coul see how long betfore one byte fails, how long before say 10 bytes fail (bit like how many "dead"/faulty pixels on an LCD screen) and how long before 10% fail.
hippy
Ex-Staff (retired)
It's worth looking through the forum for previous discussions and tests, and I'm sure a lot of comments will apply here; particularly regarding what any result shows and what that means compared to Microchip's figure which is based on more than just one or two random tests.
My guesstimate would be 5,000,000 erase cycles; half way to the the next magnitude up from Microchip's figure. Unlikely to fail at 1m, unlikely to reach 10m, so half way seems a good bet.
My guesstimate would be 5,000,000 erase cycles; half way to the the next magnitude up from Microchip's figure. Unlikely to fail at 1m, unlikely to reach 10m, so half way seems a good bet.
Buzby
Senior Member
I writing to location 0 only, but obviously a whole page is written each time.
The test is that the value written to 0 is the same when read back 5ms later.
It could be that a fault first occurs anywhere in page 0, or maybe anywhere in the memory, but testing for that will take too long.
The test is that the value written to 0 is the same when read back 5ms later.
It could be that a fault first occurs anywhere in page 0, or maybe anywhere in the memory, but testing for that will take too long.
hippy
Ex-Staff (retired)
But is it ? I honestly don't know and haven't looked at the datasheet but there can be clever tricks such as being able to set bits low without erasing the byte affected. Unless the datasheet deigns to tell us exactly how things are implemented we may never know.
There is a Microchip note on Eeprom Endurance which might give some details.
westaust55
Moderator
Microchip app note on EEPROM endurance suggests writes are on a per byte basis:
Each programming cycle is usually referred to as an erase/write cycle
Note also:
Each programming cycle is usually referred to as an erase/write cycle
Refer: http://www.microchip.com/stellent/groups/SiteComm_sg/documents/Training_Tutorials/en532276.pdf
Note also:
and
Last edited:
Buzby
Senior Member
I knew about that trick years ago with UV erasable EPROMs, where you could 'write' without 'erase', but only if bits were going low.
Microchip maybe doing something like that, but as I'm writing random bytes there will have to be an erase most of the times.
This test is not meant to be a full blown scientific investigation, just a quick(?) experiment.
So the guesses at the moment are 10M and 5M, anyone have any other guesses ?
westaust55
Moderator
If you sent a single byte at a time then you use byte write mode.
send two or more bytes in the one hi2cout command and you are using page write mode
send two or more bytes in the one hi2cout command and you are using page write mode
From Using i2c with PICAXE:
There was a previous thread where someone was exceeding the capacity of the page write buffer and their additional data was getting written over the first data. So multiple bytes would have to be in the same page to avoid this, unless a short delay is added between them.
The buffer size is 64 for a 24LC256.
There was a previous thread where someone was exceeding the capacity of the page write buffer and their additional data was getting written over the first data. So multiple bytes would have to be in the same page to avoid this, unless a short delay is added between them.
westaust55
Moderator
From the Microchip 24LC256 datasheet:
16 bytes for the 24LC16 thru 64 bytes for the 24LC256, etc
Nothing stating that one must start at a specific point. Only ensure you do not try to cross a page boundary.
16 bytes for the 24LC16 thru 64 bytes for the 24LC256, etc
Balderbraa
Member
I would guess 4,750,127
Buzby
Senior Member
1h 20min is a million counts, you are a bit late, it's just passed 3 million !
I know, so now I'm going to 6-Million as my second guess.
This is a good experiment, as I have wondered many times as to the life of EEPROM.
Buzby
Senior Member
Code:
' Interrupt
' ---------
interrupt:
' Generate another interrupt at next overflow
' -------------------------------------------
timer = 0xffff
toflag = 0
' Count writes
' ------------
inc ecount_low
if ecount_low > 9999 then
ecount_low = 0
inc ecount_hi
endif
' Test that this read = last write
hi2cin 0, (rd_val)
if rd_val <> wr_val then
inc failed
fr = rd_val
fw = wr_val
endif
' Write new value
wr_val = randwrd
hi2cout 0, (wr_val)
' Count time
' ----------
inc ms_count ' Count up in 5mS increments
if ms_count > 199 then
ms_count = 0
inc sec_cnt
if sec_cnt > 59 then
sec_cnt = 0
inc min_cnt
if min_cnt > 59 then
min_cnt = 0
inc hrs_cnt
if hrs_cnt > 23 then
hrs_cnt = 0
inc day_cnt
endif
endif
endif
endif
erco
Senior Member
That's a good thing! We need numbers at 3.3 and 5V. Christmas is fine!
inglewoodpete
Senior Member
Isn't it about now that you realise you have a bug in your code?
Buzby
Senior Member
Good Morning,Isn't it about now that you realise you have a bug in your code?
14,000,000 ... and I've purposely stopped it.
IWP's suggestion maybe true, I might have a bug.
Here is the code I was running :
Code:
#PICAXE 28X2
#NO_TABLE
#NO_DATA
sertxd ("EEPROM Test",cr,lf)
' Inputs
' ------
symbol pbStart = b.4 ' Start
' Outputs
' -------
symbol ledIntActive = c.0 ' Interrupt activity indicator
symbol ledLoopActive = c.1 ' Main loop activity indicator
symbol Hz200 = c.2 ' 200 Hz output
; hserout = c.6
' hserin = c.7
' hi2c scl = c.3
' hi2c sda = c.4
' Variables
' ---------
symbol wr_val = b0
symbol rd_val = b1
symbol ee_val = b2
symbol ms_count = w2 ' Millisecond count ( b4,b5 )
symbol sec_cnt = b6 ' Seconds count
symbol min_cnt = b7 ' Minutes count
symbol hrs_cnt = b8 ' Hours count
symbol main_cnt = b9 ' Main loop count
symbol sec_old = b10 ' Seconds memory
symbol day_cnt = w6 ' Days count
symbol randwrd = w7
symbol failed = w8
symbol ecount_low = w9
symbol ecount_hi = w10
symbol fr = w11
symbol fw = w12
' Code starts here
' ================
setfreq em64 ' Run at 64MHz
pause 10
hsersetup B115200_64, 2 ' Set serial TX parameters
pause 10
hi2csetup i2cmaster, %10100000, i2cfast_64, i2cword
pause 10
restaart:
setintflags %00000000,%00000000 ' Stop interrupting on timer overflow
ms_count = 0
sec_cnt = 0
min_cnt = 0
hrs_cnt = 0
day_cnt = 0
failed = $FFFF
ecount_hi = 110
pause 2000
hserout 0,(13,10,"EEPROM Test",13,10) ' Say hello
pause 2000
settimer 64286 ' Set timer preload value
timer = 0xffff ' Generate interrupt at next overflow
toflag = 0 ' Clear timer flag
setintflags %10000000,%10000000 ' Interrupt on timer overflow
Do 'Main_loop:
' Main loop activity indicator
' ----------------------------
inc main_cnt ' Toggle main loop activity indicator every 200 cycles
if main_cnt > 200 then
main_cnt = 0
toggle ledLoopActive
endif
' Make random
' -----------
random randwrd
' Interrupt activity indicator
' ----------------------------
if ms_count > 100 then' Toggle interrupt activity indicator every 500mS
high ledIntActive
else
low ledIntActive
endif
' Print status every second
' -------------------------
if sec_old <> sec_cnt then
sec_old = sec_cnt
gosub TXtimers
hserout 0, (" ",#ecount_hi)
pause 5
hserout 0, ("0,000")
pause 5
hserout 0,(" F=",#failed)
pause 5
hserout 0, ( " fw=",#fw," fr=",#fr)
pause 5
hserout 0,(cr,lf)
endif
Loop ' End of Main_loop
' ==============================================================================================
' ==============================================================================================
' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
' Interrupt
' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
' Interrupt
' ---------
interrupt:
' Generate another interrupt at next overflow
' -------------------------------------------
timer = 0xffff
toflag = 0
' Count writes
' ------------
inc ecount_low
if ecount_low > 9999 then
ecount_low = 0
inc ecount_hi
endif
' Test that this read = last write
hi2cin 0, (rd_val)
if rd_val <> wr_val then
inc failed
fr = rd_val
fw = wr_val
endif
' Write new value
wr_val = randwrd
hi2cout 0, (wr_val)
' Count time
' ----------
inc ms_count ' Count up in 5mS increments
if ms_count > 199 then
ms_count = 0
inc sec_cnt
if sec_cnt > 59 then
sec_cnt = 0
inc min_cnt
if min_cnt > 59 then
min_cnt = 0
inc hrs_cnt
if hrs_cnt > 23 then
hrs_cnt = 0
inc day_cnt
endif
endif
endif
endif
setintflags %10000000,%10000000 ' Interrupt on timer overflow
return ' Return from interrupt
' ==============================================================================================
' ==============================================================================================
' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
' Subroutines
' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TXtimers:
' TX time
if day_cnt < 100 then : hserout 0,("0") : endif
if day_cnt < 10 then : hserout 0,("0") : endif
hserout 0,(#day_cnt,":")
if hrs_cnt < 10 then : hserout 0,("0") : endif
hserout 0,(#hrs_cnt,":")
if min_cnt < 10 then : hserout 0,("0") : endif
hserout 0,(#min_cnt,":")
if sec_cnt < 10 then : hserout 0,("0") : endif
hserout 0,(#sec_cnt)
returnThis morning I ran the following code :
Code:
#PICAXE 28X2
#NO_TABLE
#NO_DATA
pause 1000
sertxd (cr, lf, "EEPROM Test 2",cr,lf)
pause 100
hi2csetup i2cmaster, %10100000, i2cfast_8, i2cword
pause 100
hi2cout 0, (11)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (22)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (33)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (44)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (55)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (66)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (77)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
hi2cout 0, (88)
pause 10
hi2cin 0, (b0)
pause 10
sertxd (#b0,cr,lf)
pause 10
So we have two options :
1 - There is a bug in my code, and it does not 'write' to the EEPROM
2 - The EEPROM really did keep going after 14 million writes.
Thoughts please.
Buzby
EDIT : Tested code integrity again, by commenting out the 'hi2cout'. Got just under 200 fails per second, exactly as expected, so I think the code is working OK.
Running again still at 3.3v, will be running all day as I'm going out till tonight.
Last edited: