The quick and dirty 32-bit EEPROM counter implemented on a common 24LC512 surpasses its minimum write-cycle endurance of 1 million cycles by a staggering 700% , still with not a single error. What am I doing wrong?
That's plausible, as even x10 headroom is possible.
With on chip ECC, you would not expect gradual failures.
What could be revealing, is to track the PGM cycle time, to see how that varies ?
Data says : "Note: The 24XX512 does not generate any Acknowledge bits if an internal programming cycle is in progress."
I wonder if that is 'live', ie if you address a part, and wait @ ack slot, does the EEPROM eventually drive SDA low, or must you repeat-poll (which is more granular, but could be ~ 10us at 1MHz)
There are a few things that I was going to check next time I do this although in fact I could stop it at anytime really. So perhaps I will let it cycle through to 10 million since it is already very close (>9.7 million) to that now if it gets that far that is. At present the ack bit is checked normally but I will do a test to see if that bit changes while the ack clock is held back, it may be interesting. There are two outcomes from this test though:
1) Practically of implementing simple counters in EEPROM without regard to wear.
2) Discover what the limits of EEPROM endurance are in practice and what it means when a location is worn out.
So I think so far we can see that we can implement simple counters and that the figure of 1 million write cycles minimum is a very very safe figure. However if multiple counters are organized on the same page then this has to be taken into account and optimally these counters would reside in separate pages if necessary. I was thinking that even if we do wear out a counter we could still detect that location has been worn and mark it while continuing on in the next page location etc. This would be very simple to implement and very effective too.
I've stopped the simple counting test at 10,174,110 to do a more in-depth test. A quick dump of that page reveals that the other locations look fine just as they were beforehand.
You can add code after the write to read what you just wrote and confirm it read back correctly and if not then increment the eeprom address for the data you want to store and start writing to the new area. You can store the address value at a location on the eeprom and on boot read the address value and use it until and if the data fails to verify.
You can add code after the write to read what you just wrote and confirm it read back correctly and if not then increment the eeprom address for the data you want to store and start writing to the new area. You can store the address value at a location on the eeprom and on boot read the address value and use it until and if the data fails to verify.
A variant on that, which saves needing a place & code to store the address, is to decrement on fail, and read until <> 0xffffffff. EEPROMs can sequential read, so you just start at page[0] and use top-most for counter (eg 32b).
A fail to verify, can decrement by 4, and retry (with ability to decrement & retry multiple times).
This of course presumes the cells that have 0xffffff are somehow less stressed by the repeated erase and page re-writes, than bits pgm'd to 0.
If they are slightly less stressed, then you could take a good many cycles to wear first bytes, and then somewhat rapidly fall-down the other choices, until the whole page fails to verify.
Why not just stick a cheap RTC (I2C) module on there and use the spare battery-backed RAM locations? This is what I do for part counting, etc.
+1
23LCV512 and siblings (battery backed SPI SRAM) would use more pins and probably is more expensive than a RTC....
...there would be I2C or SPI FRAM too but still beaten by a RTC when it comes to costs...
Edit @ 20170406-1354-GMT ... and there are some RTCs with FRAM... unluckily I forgot their name and somehow I currently feed the find-o-matic only with wrong search words... :-/
And you get a super accurate clock thrown-in. I just received a handful of modules for ~$3 each, complete with CR2032.
FYI, I have found the fake DS3231 chips on these modules are not super accurate, just compatible, thats all. The real chips cost more than the modules. Also I prefer the smaller modules with the tiny battery if I do use them as a CR2032 is a redundant monster that might prove useful if you only powered up your system after ten years of battery operation but by then the clock would be hopelessly wrong anyway. Otherwise I prefer a tiny supercap in place of a battery that can keep it powered for up to a week and recharges within minutes and lasts indefinitely which is more than practical and in fact that's what I do with RTCs in general. If any piece of equipment is powered off for more than a week then it usually means it is being serviced or is in storage and setting the time before using it again is always expected.
BTW, did everyone get the point that it is practical to implement simple cycle counters in EEPROM. If I used this for warranty purposes the fact that the counter location was worn out would say much more than a valid counter ever could
Hi
I wonder- I understand the writes are done in 'blocks' of maybe 256 bytes at a time, even if only a few bytes are changed. If erased bytes in the rom are all $FF and if when writing to the rom with only 16 bytes and the others are unchanged, then do the unchanged bytes suffer any wear?
If not- if the 16 bytes you are changing every reprogramming go faulty can the others in the same block still be used?
If so, then allow a safe million writes to the first set of 16 bytes, and then go on to use the next 16 bytes so that a block of 256 bytes will last 16 million updates. Then start on the next block, etc etc.
It will last for... a very long time..
Dave
BTW, did everyone get the point that it is practical to implement simple cycle counters in EEPROM. If I used this for warranty purposes the fact that the counter location was worn out would say much more than a valid counter ever could
Yes.
Thinking some more on this, the smallest code could be to simply write the 32b counter to successive locations in the same page. ie each write, (adds 4) MOD PageSize to the address.
No scans, or if tests needed.
That uses the page-REMW, and the whole page can be extracted later, and some bad-cells can be discarded to extract a count value with reasonable confidence.
Comments
Try testing the Chinese knockoff.
Have you applied enough grease? Trying smearing some around the pins. I am certain that will slow you down
With on chip ECC, you would not expect gradual failures.
What could be revealing, is to track the PGM cycle time, to see how that varies ?
Data says :
"Note: The 24XX512 does not generate any Acknowledge bits if an internal programming cycle is in progress."
I wonder if that is 'live', ie if you address a part, and wait @ ack slot, does the EEPROM eventually drive SDA low, or must you repeat-poll (which is more granular, but could be ~ 10us at 1MHz)
1) Practically of implementing simple counters in EEPROM without regard to wear.
2) Discover what the limits of EEPROM endurance are in practice and what it means when a location is worn out.
So I think so far we can see that we can implement simple counters and that the figure of 1 million write cycles minimum is a very very safe figure. However if multiple counters are organized on the same page then this has to be taken into account and optimally these counters would reside in separate pages if necessary. I was thinking that even if we do wear out a counter we could still detect that location has been worn and mark it while continuing on in the next page location etc. This would be very simple to implement and very effective too.
A fail to verify, can decrement by 4, and retry (with ability to decrement & retry multiple times).
This of course presumes the cells that have 0xffffff are somehow less stressed by the repeated erase and page re-writes, than bits pgm'd to 0.
If they are slightly less stressed, then you could take a good many cycles to wear first bytes, and then somewhat rapidly fall-down the other choices, until the whole page fails to verify.
23LCV512 and siblings (battery backed SPI SRAM) would use more pins and probably is more expensive than a RTC....
...there would be I2C or SPI FRAM too but still beaten by a RTC when it comes to costs...
Edit @ 20170406-1354-GMT ... and there are some RTCs with FRAM... unluckily I forgot their name and somehow I currently feed the find-o-matic only with wrong search words... :-/
FYI, I have found the fake DS3231 chips on these modules are not super accurate, just compatible, thats all. The real chips cost more than the modules. Also I prefer the smaller modules with the tiny battery if I do use them as a CR2032 is a redundant monster that might prove useful if you only powered up your system after ten years of battery operation but by then the clock would be hopelessly wrong anyway. Otherwise I prefer a tiny supercap in place of a battery that can keep it powered for up to a week and recharges within minutes and lasts indefinitely which is more than practical and in fact that's what I do with RTCs in general. If any piece of equipment is powered off for more than a week then it usually means it is being serviced or is in storage and setting the time before using it again is always expected.
BTW, did everyone get the point that it is practical to implement simple cycle counters in EEPROM. If I used this for warranty purposes the fact that the counter location was worn out would say much more than a valid counter ever could
I wonder- I understand the writes are done in 'blocks' of maybe 256 bytes at a time, even if only a few bytes are changed. If erased bytes in the rom are all $FF and if when writing to the rom with only 16 bytes and the others are unchanged, then do the unchanged bytes suffer any wear?
If not- if the 16 bytes you are changing every reprogramming go faulty can the others in the same block still be used?
If so, then allow a safe million writes to the first set of 16 bytes, and then go on to use the next 16 bytes so that a block of 256 bytes will last 16 million updates. Then start on the next block, etc etc.
It will last for... a very long time..
Dave
Thinking some more on this, the smallest code could be to simply write the 32b counter to successive locations in the same page. ie each write, (adds 4) MOD PageSize to the address.
No scans, or if tests needed.
That uses the page-REMW, and the whole page can be extracted later, and some bad-cells can be discarded to extract a count value with reasonable confidence.