Sotring a "counter" in EEPROM
TC
Posts: 1,019
in Propeller 1
Hello all,
I am sorry if this is a very simple question, I am under a very short deadline and I don't have the time to experiment with ideas I have.
I am working on a setup that is testing the durability of a part. There could be 100,000+ cycles this project will have to do. To make sure the cycle counter is not forgotten if there is a power outage, someone kicks the plug, etc.. after every cycle, the prop would store the counter value in the EEPROM. But I am worried about the number of writes to the EEPROM. I know the datasheet says "More than a million erase/write cycles" But I am worried that statement is on the high side of the durability of the EEPROM.
My question is, should I be worried? is there a good way to write to the EEPROM 100,000 times, and not have the chance of making the EEPROM quit working?
Thank
TC
I am sorry if this is a very simple question, I am under a very short deadline and I don't have the time to experiment with ideas I have.
I am working on a setup that is testing the durability of a part. There could be 100,000+ cycles this project will have to do. To make sure the cycle counter is not forgotten if there is a power outage, someone kicks the plug, etc.. after every cycle, the prop would store the counter value in the EEPROM. But I am worried about the number of writes to the EEPROM. I know the datasheet says "More than a million erase/write cycles" But I am worried that statement is on the high side of the durability of the EEPROM.
My question is, should I be worried? is there a good way to write to the EEPROM 100,000 times, and not have the chance of making the EEPROM quit working?
Thank
TC
Comments
I know there have been some designs shared here that monitor the AC waveform to trigger the same method. It all depends on how your power supply is setup for your test device.
You could use a block of 2048 bytes using it as an array of 256 x 8 byte entries to store the 4 byte counter plus a 4 byte serial number that's incremented every time you write an entry to the EEPROM. You can identify which entry is stored last from the serial number assuming there's enough power to complete the last write if an outage occurs when storing a value and the system stops before starting to store a new value. In other words, you need to detect a power outage and have maybe 100ms of power available before shutting down in an orderly fashion.
Even if your project counts 10 times the 100,000 you are still "safe" as that figure is the "minimum". Do not read "minimum" the same way we read "absolute maximum" as that is a very different parameter.
Most programs don't reach high into the 32K, so you could always save the cycles count up there, and even use an array to spread things around. If you're using a 64K EEPROM (I always do), you can write the value in the upper 32K to be persistent between apps.
Here's a quick idea off the top of my very tired head (only works in lower 32K)
pub update_cycles | cmax, lidx, n cmax := -1 ' initialize to minimums lidx := 0 repeat n from 0 to 7 ' look for last highest if (long[EE_CYCLES][n] > cmax) cmax := long[EE_CYCLES][n] lidx := n lidx := EE_CYCLES + ((++lidx & %111) << 2) ' convert to address ee.wr_long(lidx, ++cmax) ' write to EEPROM return cmaxThat was my first thought, but it would be my luck where it did not work the one time we need it to.
Maybe I am over thinking how many writes will be made. One idea I did have was to only store 256 counts per memory location, then just add the memory location together. 256+256+256+4=772. But I dont this I need to got that far.
Almost sounds like my idea from Mike Green. Just bigger.
I think you are exactly right. I am overthinking it. I am going to stick with the easy route right now, then later if there is a need do the more complex route. Thanks Peter.
I love it when you reply Jon, your code always make me dig deeper into why you do what you did. Thanks.
Check that the 1M is the min & under what conditions, but be aware if your power fails abruptly during a write, you will have a write failure.
If you do go to wear level, read the fine print as some parts read/modify/write more than one byte at a time.
The simplest is probably to write value in 2 or 3 places, and then compare them.
Seems most EEPROM have 5ms byte/page write times, but I see the new Adesto parts spec 60us byte writes
Adesto also make these claims... RM24C512C-L data
"The Byte Write operation of Mavriq memory consumes only 10% of the energy consumed by a Byte
Write operation of EEPROM devices of similar size.
Adesto's EEPROM endurance can be as much as 40X higher than industry standard EEPROM devices operating in byte
write mode at 85°C. Unlike EEPROMs based on floating gate technology (which require read-modify-write on a whole
page for every write operation) CBRAM write endurance is based on the capability to write each byte individually,
irrespective of whether the user writes single bytes or an entire page. Additionally, unlike floating gate technology,
CBRAM does not experience any degradation of endurance across the full temperature range. By contrast, in order to
modify a single byte, most EEPROMs modify and write full pages of 32, 64 or 128 bytes. This provides significantly less
endurance for floating gate devices used in byte write mode when compared to page write mode.
The Page Write operation of Mavriq memory is 4-6 times faster than the Page Write operation of similar EEPROM
devices."
Mine works every time. Very simple really.
After 20 minutes I decided to terminate it and have a look since I forgot to put in some reporting
So that counted to over 100,000 without any problems. I will now leave it running with a loop that reports count and verifies the count as well, stopping on the first error.
I will let you know later on when I get back and check as this loop is going as fast as the EEPROM will let it.
Remember, it is only the location that can suffer wear, not the whole EEPROM.
Do you have the part number of the EEPROM, for reference.
The Adesto parts look slight variants on a the classic EEPROM.
It should work on your Propeller serial terminal and you just have to input values and press enter. You'll see values stored from array element 1-5 and then start again from 1-5.
http://www.computing.dcu.ie/~humphrys/Notes/Networks/data.hamming.html
Upon reading the number back, you will know with a high degree of certainty if one or two bits got clobbered and be able to correct the count if only one bit got clobbered.
-Phil
I believe many of the ones that claim 1M cycles, already implement ECC
Google also finds this :
http://hackaday.com/2014/12/04/flash-memory-endurance-testing/
ftp://ftp.microchip.com/tools/memory/total50/tutorial.html
But no, I don't seriously recommend such. I like the idea above of storing just every 10th (or <n>th...) value. KISS. And I hated to replace that battery (that is de-solder the old and solder the new one in) providing power to a RAM holding valuable calibration data, while the unit is powered on.
-Phil
Here is the screenshot of the console reporting where it is up to. Mind you I had already counted to well over 100,000 prior to all this on the same location.
Reading the 'fine print' you can probably get wider statistical coverage, in a simple manner :
"Note: 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."
I read that as the chip does a Page Read/Erase/Write, and bytes not refreshed in the page by the user, are simply cloned again.
(but all 128 are erased)
This also means 'wear-leveling' could well be a mirage, if you do not carefully consider page Size.
'Walking through' a page will not 'cycle bytes less-often', but it may give a means to recover, if the values increment.
ie redundancy is more useful/easier than wear-leveling.
This Page cycle, means you could fill the page with 00H, (or 0x55) before starting the test, then read checks the whole page for unexpected values.
i2c Write can still be shorter, as you change just 4 bytes.
Another approach is to write 4 bytes, then repeat the Lower byte 124 more times, then read.
Because you roll that 1,000,000 dice many more times, you should see earlier failures using 128 samples.
In a link I gave above for flash, they found the failures grouped in clusters on the physical page, so that is another effect to watch for...
That may mean a failure is less like 'flickering' and more good/bad transition, when ECC eventually hits too many bits...