eeprom endurance

PiX

New Member
An old subject I know, without much in the way of definitive conclusion other than to rely only upon the Microchip data.
So how to avoid exceeding the internal eeprom stated minimum endurance?

I have a project which uses a 20M2 to control a sequence of events (a cycle). I count every cycle and write it to eeprom so that it can be recalled after a power off-on.
My question is this: if every eeprom location individually has the same minimum endurance could my code detect that my counter is nearing the limit and switch to using an alternative eeprom address?
 

inglewoodpete

Senior Member
The predicted life of EEPROM is not finite, so you'll never know when you're getting close to the limit.

A better solution would be to write your code to cycle through a number of locations. With careful management of your data, this could multiply the longevity of your EEPROM utilisation. You don't say how many values (bytes) you want to maintain.
 

PhilHornby

Senior Member
I've been wondering about this problem of late...

Won't all available EEPROM locations be written (ie refreshed), as a 'page', whenever a single byte is updated?

If so, isn't there a chance that they'll all die together?

I was thinking of using battery-backed I²C RAM instead - in the form of an DS1307/DS3231 RTC module...
(The DS1307 has 56 such bytes, but the DS3231 seems to only have 7 (still investigating... :) )
 

papaof2

Senior Member
FRAM - 1960's magnetic core storage on a chip - probably has longer life than eeprom and it's I2C. You may have to solder an SMD chip to a header to use them - but if this old man (70+) can do that (with a good magnifier) you probably can ;-) I have used them with PICAXE chips.

Do phrase your search as "memory chip fram" or you'll be looking at oil and air filters...
 

inglewoodpete

Senior Member
I've been wondering about this problem of late...

Won't all available EEPROM locations be written (ie refreshed), as a 'page', whenever a single byte is updated?

If so, isn't there a chance that they'll all die together?

I was thinking of using battery-backed I²C RAM instead - in the form of an DS1307/DS3231 RTC module...
(The DS1307 has 56 such bytes, but the DS3231 seems to only have 7 (still investigating... :) )
According to the PIC16F1829 datasheet, the internal EEPROM is byte addressable, with a minimum byte endurance of 100,000 writes. The entire EEPROM should survive a minimum 1,000,000 erase/write cycles (typically 10,000,000) before a full EEPROM refresh is required.
 

AllyCat

Senior Member
Hi,
Won't all available EEPROM locations be written (ie refreshed), as a 'page', whenever a single byte is updated?
................
I was thinking of using battery-backed I²C RAM instead - in the form of an DS1307/DS3231 RTC module...
(The DS1307 has 56 such bytes, but the DS3231 seems to only have 7 (still investigating... :) )
No, as IWP indicates, it is normally External Serial (I2C) EEPROM devices which are organised with "pages" of 16 or 64 bytes, where "careless" programming could cause a chip to wear out up to 64 times faster than expected. :(

Does the DS3231 have any User RAM ? AFAIK the "User Buffer" is only a "pipeline" for the (7) time registers, to ensure that the register values don't update (overflow and carry to the next byte) whilst they are being read via the Bus. I have wondered if the (8) "Alarm" registers could be used as a small NV scratchpad, but can they store a full byte, or only in BCD format, or similar? There does appear to be the one byte allocated for "Aging Offset" ($10), which could be used for any (other) "User function".

The DS3232 does have additional NVRAM but these "bare" chips seem to carry a large price premium; maybe the reason why I've never seen a RTC module or breakout board using them. A significant number of DS3231 modules do include a separate I2C serial EEPROM, but that takes us back to the "wear out" issue. However, these EEPROMs can be so large that "levelling" the wear over the whole chip might easily solve the problem. Personally, when I needed some "RAM", I used a Microchip MCP7940N RTC chip which has additional SRAM, but like the DS1307, it requires an external crystal, etc., so lacks much of the convenience (and probably accuracy) of the lovely little "DS3231 for Pi" and similar modules.
_______

But back to the OP's question. Probably the first thing to do is to ensure that byte(s) is/are only rewritten when they need to be changed, i.e. perform a Read before (every) Write. Also you can ignore "wear out" if bytes are to be written less frequently than an average of (say) every hour over the full life of the application. Thus, is it necessary to write the data more frequently than every hour, or could it be "buffered" in RAM, with the risk that up to an hour's data might be lost? Of course some may be lost anyway if power is missing for a significant time.

If you "spread" the data throughout the EEPROM to "level" the wear, then you need a "pointer" to where the last data was stored, but must ensure that the pointer location itself doesn't wear out! Maybe you count (in RAM) up to (say) 1000 writes and then update the EEPROM area / pointer, and/or each time power is applied? Alternatively, organise the EEPROM as a "Circular Buffer", incrementing the (RAM) address pointer at every (block) write, and maintain a unique "Start/End Of Buffer" pattern of bytes in the EEPROM, which can be searched-for when power is re-applied.

An alternative method is "Power Fail" detection ; A PICaxe can run on such a low current that a supply decoupling capacitor can keep it running for long enough to store any "current status" data. The majority of PIC(axe)s have sufficient on-chip hardware (Voltage Reference, Comparator, etc.) to generate an "interrupt" with little on no external hardware (maybe a pin and diode, or a couple of resistors).

Cheers, Alan.
 

inglewoodpete

Senior Member
If you "spread" the data throughout the EEPROM to "level" the wear, then you need a "pointer" to where the last data was stored, but must ensure that the pointer location itself doesn't wear out! Maybe you count (in RAM) up to (say) 1000 writes and then update the EEPROM area / pointer, and/or each time power is applied? Alternatively, organise the EEPROM as a "Circular Buffer", incrementing the (RAM) address pointer at every (block) write, and maintain a unique "Start/End Of Buffer" pattern of bytes in the EEPROM, which can be searched-for when power is re-applied.
Another option is to configure a Circular buffer in EEPROM. When a value has changed and needs writing (refer to Alan's Read-Check-WriteIfChanged process, above) to the next location of the Circular buffer, next+1 is set to a "safe" or null value like $FF. If the PICAXE reboots for any reason, its startup routine would search the Circular buffer for the null value and set its pointer to that value. This method requires a doubling of EEPROM writes but we're currently assuming that only part of the EEPROM is being used.
 

PiX

New Member
Thanks for your replies.
Inglewoodpete - would you kindly explain 'full EEPROM refresh' please.
 

inglewoodpete

Senior Member
Thanks for your replies.
Inglewoodpete - would you kindly explain 'full EEPROM refresh' please.
While I have qualifications (and a long career) in electronic engineering, I do not consider myself to be an expert on EEPROMs.

My understanding is that EEPROMs have good long-term data retention: the PIC16F1829 chip that the 20M2 is built on has a specification of 40 years. However if you regularly update a range of cells, all of the others will tend to gradually lose their 'state'. While we regard EEPROM as a digital device, each memory cell is ultimately analogue in nature and will gradually lose its clear '0' or '1' state as the whole EEPROM is used. I assume this is caused by electrical noise on the power rails and busses within the chip when digital activity happens in nearby cells and that writing to the EEPROM would cause significantly more degradation than reading.

From what I've read on the subject, a 'full EEPROM refresh' would involve periodically reading and rewriting each byte in the EEPROM. You would have to base the period between refreshes by how much of a pounding you give the overall EEPROM.
 

Buzby

Senior Member
This extract from a long running thread showed that a 24LC256 survived over 14,000,000 writes before failing, way above the specified 1,000,000 ...


The general conclusion was that there is no need to worry about EEPROM wearout, unless you are writing hundred of times per second !.

A simple calculation shows that if you write once per hour, the chip will last 1,000,000 hours before the datasheet value is reached.

A million hours is 114 years !.

Cheers,

Buzby
 

westaust55

Moderator
The DS3232 does have additional NVRAM but these "bare" chips seem to carry a large price premium; maybe the reason why I've never seen a RTC module or breakout board using them. A significant number of DS3231 modules do include a separate I2C serial EEPROM, but that takes us back to the "wear out" issue. However, these EEPROMs can be so large that "levelling" the wear over the whole chip might easily solve the problem. Personally, when I needed some "RAM", I used a Microchip MCP7940N RTC chip which has additional SRAM, but like the DS1307, it requires an external crystal, etc., so lacks much of the convenience (and probably accuracy) of the lovely little "DS3231 for Pi" and similar modules.
I had purchased and did some work with a DS3232 some years ago (2013). At that time I posted a guide to some RTC chips and a basic PICAXE program for the DS3232:
Getting Started with the DS3232 RTC and a brief comparison of some other RTC chips | PICAXE Forum

Recall I had purchased a Freetronic module for around AUD$12 at the time of my original thread.
The current pricing for a DS3232 module including battery holder is quite variable.
Futurlec is US$12 DS3232 Real Time Clock Mini Board (futurlec.com)
But Core Electronics want AUD$27 ! :eek:
As AllyCat indicates, the price of a DS3231 is far less but that does not have the 236 bytes of battery backed RAM.


FRAM - 1960's magnetic core storage on a chip - probably has longer life than eeprom and it's I2C. You may have to solder an SMD chip to a header to use them - but if this old man (70+) can do that (with a good magnifier) you probably can ;-) I have used them with PICAXE chips.

Do phrase your search as "memory chip fram" or you'll be looking at oil and air filters...
I bought through hole FRAM memory chips around 12 years ago but seems they are now all SMD.
But as Papaof2 states, hand soldering of SMD chips is quite easy with a little practice. Until the pins get down to around 0.5mm centers !
I have hand soldered hundreds of SMD chips, nearly all onto SMD to through hole adapters - largest chip was around 32 pin to recollection.
 

erco

Senior Member
A simple calculation shows that if you write once per hour, the chip will last 1,000,000 hours before the datasheet value is reached.

A million hours is 114 years !
TYVM, Buzby, I can actually sleep now.
 

AllyCat

Senior Member
Hi,
A million hours is 114 years !.
The Microchip Data Sheet specification for the internal EEPROM (Data) is 100k writes, which is why I chose a ballpark period of 1 hour = 11 years, as a reasonable "lifetime". ;)

However, I received a notification of an (incomplete) post that the OP appears to have withdrawn (or accidentally lost?) which said:
"I want to count the number of 'cycles' my system performs to a maximum of 16 million. It has to be powered down after each cycle. Currently I increment then write the variables b1, b2 and b3 to three eeprom locations each time a cycle is completed. ....".

If a "cycle" took one second (a PICaxe is unlikely to boot much faster), then this could complete in about 6 months, so the EEPROM could fail before then, unless coded with care. However, my first question would be whether it is really necessary to power-down and Restart the PICaxe for every cycle. Perhaps some other part of the Hardware needs to be Reset, but the PICaxe might be "Restarted" by Emulating a Reset, or maybe by using the RESET command. I don't know if the M2s reset all 512 of their RAM locations with a software Reset (the simulator doesn't), but there's probably a SFR somewhere that could be used as a scratchpad for the least significant byte, if necessary.

However, if it is necessary to use the EEPROM, then it's only the Low Byte which might wear out. The Middle Byte needs to be updated only 65,536 times and the High Byte 256 times, although it might be updated at the same time as the Middle byte to give a "Refresh". Then, I think I'd use the Middle byte as a "pointer" to the Low Byte, for example starting at address 6. The contents at that address would be incremented for each "cycle" until it reaches (overflows to) zero, then increment the Middle byte and start incrementing location 7, etc.. After location 255, the process/counter would return to address 6, etc..

Like Pete, I'm not an expert on EEPROM technology, but I believe that the Write cycle generates an internal "Boost" voltage to assist Electron Tunneling, so there is more scope to "damage" (wear out) the fabric of the chip than a simple Read cycle. IIRC the Microchip Data Sheets refer to a "Full Refresh", without giving any further details or a Reference. However, most memory technologies are organised as an array of cells in two (or more) dimensions, e.g. "Rows" and "Columns", so there is scope for "crosstalk" between cells on the same drive line. AFAIK the data bit is stored in the form of charge (Voltage) on a "Capacitor" so it's not surprising that it may need occasional refreshing. Some memory technologies (such as magnetic core and DRAM) actually rely on a "Destructive Read" so must be Refreshed after every Read cycle; For example in a core store, a specific bit value is written to the target magnetic core (bit) and if a pulse is detected on the common "Read Line" (caused by the magnetic direction being flipped) then it must have contained the complementary bit value (so is then Rewritten with the correct value again).

Cheers, Alan.
 

westaust55

Moderator
The RESET command is supposed to do the same as disconnecting and restoring power and according to the online Command reference this includes reset of all variables, the stack and “etc”. Refer:
That is not categoric as to whether non variable RAM is also reset (that may be under the “etc”). A test could be in order on an actual chip.
 

PiX

New Member
This is the missing post AllyCat refers to ...

I am using three variables b1, b2 and b3 to count to over 16m 'cycles' of my system. 256^3=16,777,216
Every 'cycle' requires a subsequent power down and power up (not negotiable) so I write the variables to three eeprom locations prior to power down and read them back after a power up so that counting can continue where it left off.

If it is correct that every read and write reduce the lifetime of a single eeprom location (not the whole 'page') and that 100k is the Microchip guaranteed minimum then does that mean that the maximum count I could reliably store would combine two eeprom locations counting to 50k and that counting to 16m would be 'out of spec'.
For a word variable the lower byte would be written and read 50k times and the upper 195 times (256*195=49,920).
The system is for commercial use and I don't want to tell my customer it can count to 16m if that won't be reliable.

Hence then my idea that once eeprom locations 'have no lives left' I move the counting to 'newborn' locations.

I'm hoping somebody will tell me that an eeprom location is only overwritten (the state of the internal hardware altered) when the variable you write to it has changed and not that a life is used just because of the write. Also perhaps that a read doesn't use up a life?


Some of the questions my post has prompted have now been answered.
1) AllyCat has said that Microchip specify 100k writes and so I assume reading doesn't use up a 'life'.
2) The 14m lives of an eeprom Buzby refers to is probably best disregarded if your product is for commercial use.
3) For those who missed it the power cycle is non-negotiable - I won't bore you with the reason!


My remaining one though, to determine the max counter, is...
If I write to both the lower and upper bytes every 'cycle' does the lower byte continue to use up a 'life' once it reaches 255 and is then overwritten as the upper byte starts incrementing?
 

Aries

New Member
Reads do not affect the life of a memory location, it is only writes.
If the value you are going to write to an EEPROM location is the same as the one already there, you will still use up a life. The simplest way to avoid wasting lives is to check before writing ...
Code:
' assume writing b0 to location MEM
  read MEM,b1
  if b0 <> b1 then
    write MEM,b0
  endif
 

bpowell

Senior Member
I think it all depends on how frequently you look to write your variables ... if you're design is going to exceed 100k writes to a cell, or 1M total to the EEPROM, then EEPROM might not be the right solution. I'd look into NVRAM or EERAM ... I've recently picked up a couple of EERAM chips to play with ... ideally, if you need to power-cycle the PICAXE, but can leave the EERAM powered up, you should have unlimited read/write.
 

AllyCat

Senior Member
Hi,

AFAIK, the number of reads can be "infinite", but the EEPROM WRITE is always an ERASE + WRITE cycle, so it will "damage" the chip even if the stored value is NOT changed. Therefore, the primary rule is NOT to write to any byte (cell) unless it NEEDS to be changed; there might be a secondary requirement that any/all cells should be "Refreshed" occasionally. But none of these parameters have "absolute" values because they may be affected by temperature, voltage and other (unknown) environmental factors. The "lifetime" of EEPROM cells is not a "Fixed" value for a particular manufacturer (or process), or even for a particular chip: Microchip specify a minimum of 10,000 writes for the Program EEPROM, 100,000 for the Data (Read/Write) area and 1,000,000 writes for their External Serial (I2C / SPI) EEPROMs.

If you really need 16M "power cycles" (noting than some other components such as mechanical switches and Relays, etc. may have a much shorter predicted lifetime) then you probably do need to take some precautions against EEPROM Wear-Out, or to specify a "typical / predicted" lifetime instead of Microchip's minimum (perhaps highly pessimistic) specification. Also, there should be no issue with the "Centre" or "High" Bytes (b2 and b3), it is only the Low Byte (b1) which carries a risk of wear-out. It you want to limit the number of writes (of b2 and b3) to 100k in 16M "cycles", then you need a "pre-scaler" of 160; that could be a "Round Robbin" of 160 EEPROM cells or some other (external) hardware method (you haven't indicated if the EEPROM is required for any other purposes).

You haven't indicated the longest duration of the "Power Down" period; if it's relatively short then a "prescaler" value might be stored on a capacitor (or two) via a PWM "DAC" output and subsequent ADC input measurement. Or if the period between "cycles" is to be large, then how will they ever get up to 16 million ?! However, so much depends on the nature of the application; what other (useful) hardware might be available (or might be added), and what can be the cost/benefit of specifying these "16M cycles", etc. ? BTW, don't overlook that the EEPROM has a minimum "Write" cycle time (IIRC around 5ms), so that must be accommodated in the coding, as well as minimising the number of "essential" Writes.

Cheers, Alan.
 

AllyCat

Senior Member
Hi,

Yes indeed, and there may be other issues with power-cycling a PICaxe 16 million times, apart from its EEPROM Endurance. As already said, any "mechanical" components such as switches or connectors may have a much shorter lifetime, but a search of the Microchip website produced some "interesting" links: I had expected there to be an "AN" (Application Note) for EEPROM Endurance, but I couldn't find one ! :( However there are two which might be "relevant":

AN1095 : Emulating Data EEPROM for PIC18 and PIC24 MCUs and dsPIC33 DSCs (downloaded via a Google link, because the Microchip link appears broken). Not directly relevant because it uses the PROGRAM EEPROM which is not accessible in a PICaxe, because this needs "illegal" SFRs. However, it appears to employ an array of cells to store each data byte to extend the Write Endurance

AN3399 : Safeguarding Flash Memory Self-Write Operations. Again more concerned with PROGRAM EEPROM, but it highlights some "issues" that might occur each time that a PIC(axe) goes through a power cycle. Can we be sure that a PICaxe doesn't perform a single "accidental" write to any EEPROM cell when it performs its (complex) boot-up procedure (clearing RAM and ititialising SFRs, etc.)? Have Rev. Ed (or anybody else) ever tested for an excess of 10 million power cycles of a PICaxe?

Also two threads on the Microchip forum, which show how it can be too easy to "Overthink" (or more likely "Underthink") issues like these:

ATtiny25 internal EEPROM endurance : Which has received no "answers", even after a "bump", and

Does Re-Writing the Flash Every 5 Years "Solve" the 20 Year Endurance Issue? : Again concerned with Program EEPROM but demonstrating the Under/OverThink issues. ;)

Cheers, Alan.
 
Top