Shop OBEX P1 Docs P2 Docs Learn Events
Sotring a "counter" in EEPROM — Parallax Forums

Sotring a "counter" in EEPROM

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
«1

Comments

  • How long are the cycles? If they are short, may save every 10 cycles.
  • TCTC Posts: 1,019
    There is 30 seconds between cycles.
  • Don MDon M Posts: 1,647
    edited 2017-04-04 14:41
    What I have done in the past for this sort of thing was to monitor the DC voltage prior to the 3.3V regulator using a voltage divider connected to one of the pins of the Propeller. If the voltage starts to fall below the high threshold of the pin then it executes the EEPROM storage method to save the data. This assumes that there is sufficient capacity (as in large enough capacitors) that the voltage decays slow enough for the save method to complete. That way you only write to the EEPROM when needed.

    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.
  • The "million erase/write cycles" is a minimum and is for a specific memory location. If you use two locations, you can do a million cycles or more to each location. That's one cycle every 30 seconds for a year.

    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.
  • Another option is to spread the "wear and tear" over the entire top half of the EEPROM. If your board has the AT24C512 EEPROM there will be 110 pages of 128 bytes each above address 0x8000. Internally, the EEPROM does all writes in page mode, it does not erase and write more than 128 bytes at a time. Simply store your information, say 100 times per page, then move on to the next one, etc.
  • Stop overthinking it, this is the sort of stuff that you can make way complicated if you try to err on the super super safe side or as some would say "just to be safe". Do you fill up your tank every time you drive to the local shops "just to be safe"? So therefore there is a degree of absurdity in these "just to be safe" scenarios.

    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.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2017-04-04 16:00
    EEPROM are cheap -- if this is for testing, let that part be sacrificial if required.

    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 cmax
    

  • TCTC Posts: 1,019
    Don M wrote: »
    What I have done in the past for this sort of thing was to monitor the DC voltage prior to the 3.3V regulator using a voltage divider connected to one of the pins of the Propeller. If the voltage starts to fall below the high threshold of the pin then it executes the EEPROM storage method to save the data. This assumes that there is sufficient capacity (as in large enough capacitors) that the voltage decays slow enough for the save method to complete. That way you only write to the EEPROM when needed.

    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.

    That was my first thought, but it would be my luck where it did not work the one time we need it to.



    Mike Green wrote: »
    The "million erase/write cycles" is a minimum and is for a specific memory location. If you use two locations, you can do a million cycles or more to each location. That's one cycle every 30 seconds for a year.

    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.

    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.

    Hal Albach wrote: »
    Another option is to spread the "wear and tear" over the entire top half of the EEPROM. If your board has the AT24C512 EEPROM there will be 110 pages of 128 bytes each above address 0x8000. Internally, the EEPROM does all writes in page mode, it does not erase and write more than 128 bytes at a time. Simply store your information, say 100 times per page, then move on to the next one, etc.

    Almost sounds like my idea from Mike Green. Just bigger.


    Stop overthinking it, this is the sort of stuff that you can make way complicated if you try to err on the super super safe side or as some would say "just to be safe". Do you fill up your tank every time you drive to the local shops "just to be safe"? So therefore there is a degree of absurdity in these "just to be safe" scenarios.

    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.

    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.


    JonnyMac wrote: »
    EEPROM are cheap -- if this is for testing, let that part be sacrificial if required.

    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 cmax
    

    I love it when you reply Jon, your code always make me dig deeper into why you do what you did. Thanks.
  • jmgjmg Posts: 15,140
    edited 2017-04-05 00:48
    TC wrote: »
    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?
    It is always good to be worried :)
    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."
  • Don MDon M Posts: 1,647
    TC wrote: »
    Don M wrote: »
    What I have done in the past for this sort of thing was to monitor the DC voltage prior to the 3.3V regulator using a voltage divider connected to one of the pins of the Propeller. If the voltage starts to fall below the high threshold of the pin then it executes the EEPROM storage method to save the data. This assumes that there is sufficient capacity (as in large enough capacitors) that the voltage decays slow enough for the save method to complete. That way you only write to the EEPROM when needed.

    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.

    That was my first thought, but it would be my luck where it did not work the one time we need it to.

    Mine works every time. Very simple really.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-04-05 00:40
    I ran a quick test in Tachyon incrementing a long in EEPROM with this code:
    1000000 0 DO $FFFC E@ 1+ $FFFC E! LOOP
    

    After 20 minutes I decided to terminate it and have a look since I forgot to put in some reporting
    Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
    --------------------------------------------------------------------------------
    ( 0001 $334C VSR )   $FFFC E@ .
    134382
    

    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.
    ---	cnt     report              save to ee   read ee  verify  keep counting  else report failure
    	0 BEGIN <CR> DUP PRINT SPACE  DUP $FFFC E! $FFFC E@ OVER = WHILE 1+ REPEAT CR PRINT" FAIL @ " PRINT	
    

    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.
  • jmgjmg Posts: 15,140
    That's ~ 8.9ms per cycle.
    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 seems like 8.9ms that's true but remember we are writing 4 bytes and also reading 4 bytes from I2C EEPROM every count as well as reporting. At 400kHz I2C speed we need to issue at least 7 bytes for a write plus the read so that would take around 500us or so. Anyway, I will check this figure later after I have run the tests as my EEPROM routines wait for the chip to acknowledge instead of blindly waiting 5ms. Maybe that is a bug and my routine times out anyway which is not a problem for page writes and hardly noticed for random writes except when you do them one after another.
  • lardomlardom Posts: 1,659
    edited 2017-04-05 02:49
    I tried to build a simple 5 element wear leveling object some years ago when I had less experience than I do now. This means I don't know if it will actually accomplish wear leveling but I'll post it and you are welcome to check it out.
    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.
  • For the truly paranoid, you can always store your counter using a Hamming code:

    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
  • jmgjmg Posts: 15,140
    For the truly paranoid, you can always store your counter using a Hamming code:
    How does that behave, on a chip that already has ECC in the cells ?
    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

  • Well over 2 million program/verify cycles and still counting.......
  • 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.
  • Well, while on the paranoid side of 'just to be safe' ... in the olden days battery backed RAM was used: unlimited, fast writes, with byte addressing granularity and no worrying about wear leveling internal controllers spreading writes. Lithium-ion (non-rechargeable) batteries were used with a life expectancy of 10 years. I just replaced one of those in an instrument which had a date code of 10/93 and still provides more than 3.6V (nominal 3.6V). Not sure if those batteries ever die ...

    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.
  • Depends what you're doing. If my customer makes even one part too many, he has several hundred bucks on his hands that he has no use for. Heck I was doing this back in my DOS-PC-based embedded controls to avoid writing to the HD. The PC's RTC had spare RAM locations that I accessed. Later motherboards/BIOS/whatever required recalculating a checksum which was no biggie. Many hundreds of those systems still running.
  • jmg wrote:
    How does that behave, on a chip that already has ECC in the cells ?
    Like a belt and suspenders! :)

    -Phil
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-04-05 07:00
    So guys, having dealt with these issues in so many projects myself where I have had concerns about EEPROM endurance I however don't see a problem with storing a cycle count of a maximum of around 100,000 which also seems a way bit on the high side anyway (of counting any application "cycle" that is, not about endurance) . My EEPROM test on a standard Microchip 24LC512 has progressed well past 2 million cycles so there is at least the low byte of that counter which has definitely cycled that much in case some chips don't erase and reprogram the same value, although they do indeed seem to. But any OP that asks a sensible question on this forum will end up with many opinions although very few will actually be backed up (excuse the pun).

    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.
    1018 x 109 - 24K
  • IIRC, a similar test was performed on the Backshed forum and although the EEPROM didn't altogether die, writes became unreliable.
  • 3 million cycles and still counting (again, forgive the pun :) )
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-04-05 13:07
    In 2016 the population of New Zealand was 4,565,185 not including sheep. So far the EEPROM has managed to count this many in a single 32-bit location without any errors. Progressing on towards failure but not having any luck yet :)
  • In the Land of the Midnight Sun there are over 5,271,958 people not including Reindeer. The EEPROM's endurance is certainly being tested by this stage. The question is: when will it fail? Will wear leveling need to be introduced to count up to 100,000 in EEPROM, just to be safe?
  • jmgjmg Posts: 15,140
    edited 2017-04-05 20:10
    In the Land of the Midnight Sun there are over 5,271,958 people not including Reindeer. The EEPROM's endurance is certainly being tested by this stage. The question is: when will it fail? Will wear leveling need to be introduced to count up to 100,000 in EEPROM, just to be safe?
    Interesting.

    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...

  • When this chip eventually fails I was planning a page test too. I had expected to come back to it this morning and find that it had stopped but the cycle counter has passed 7.8 million.
  • jmgjmg Posts: 15,140
    When this chip eventually fails I was planning a page test too. I had expected to come back to it this morning and find that it had stopped but the cycle counter has passed 7.8 million.
    Microchip suggest this gets quite a lot worse at elevated temperatures, they spec >1M at 25°C & I think they use ECC on the die, so store more than 8 bits per byte.
    That may mean a failure is less like 'flickering' and more good/bad transition, when ECC eventually hits too many bits...
  • In the Confederation of Cantons there are around 8,379,477 people not counting chocolate, cheese, or timepieces. 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?
Sign In or Register to comment.