Maximum writes to M2 EEPROM

jims

Senior Member
I believe that in some PICAXE manual I have seen a statement about the maximum number of times that the onboard M2 EEPROM can be written. I've searched thru Manuals 1,2,3 using a search argument "max" & can't find it. Can someone please give me a clue where to look?
Thank you in advance.
Jims
 

westaust55

Moderator
The life of the EEPROM memory is a function of the native/raw Microchip PIC used by Revolution educaiton for the PICAXE parts.

If you go to the PICAXE website here:
http://www.picaxe.com/What-is-PICAXE/PICAXE-Chip-Labels/
There is a link to the corresponding PIC datasheets.
For the older PICAXE parts see here:
http://www.picaxe.com/What-is-PICAXE/Superseded-Parts/

Not all of the datasheets state the EEPROM and Flash memory life but from the 40X2 5V datasheet it states:
1,000,000 erase/write cycle Data EEPROM memory typical
It can be worthwhile have a look at the PIC datasheet to get an appreciate of what happens in the background when your PICAXE BASIC program is run and what has to happen "behind the scenes".
 
Last edited:

Dippy

Moderator
Westy, I've looked at the 18F45K22 datasheet. I can't find the figure of 1million you mention.

I can only see a (per cell/byte) figure of 100,000. (With 10,000 for Flash). It's not to be confused with total array erase/write/refresh.
Can you point me to the page please , I must be going blind.

One other thing to keep in mind; these figures are statistical. You may get many more erase/write cycles but the level of confidence reduces.
In any event it's a good idea to keep your writing to a minimum and, if possible, spread it around the EEPROM array.
 

jims

Senior Member
You need to go to page 337, where you will find the minimum endurance specified for a single byte is 100,000 ........
There has been a lot of good "back & forth" on this since I asked the question. From the info that I've seen I believe that I will be safe writing to the same byte on an M2 part at least 274 times each day for one year (274x365=100010). Is this correct, or am I missing something? Jims
 

Dippy

Moderator
That sounds about right jims. But if your "at least 274" turns into 500 then you might be pushing your luck ;)

The datasheet says 100K 'min', that implies at-the-very-least you should be able to write 100K times.
It doesn't mean numbers higher than that are guaranteed. Be aware of statistics.

As I said before, these figures are statistical (based on a number of tests on a number of samples).
So, Microchip are confident (in the statistical sense of 'confidence' and uncertainty) that you will be able to do it 100K times minimum.
This could mean 100,001 or 200,000 times, but as the number goes up the confidence comes down - that's stats.

If, however, you can spread your data writing to EEPROM over more than one 'cell' or cells (i.e. don't keep banging away on one particular cell) then you can increase the overall life. With a little planning your byte writing could be several x 100s of K. That's the rough idea behind a lot of Flash storage you buy .

There may be some test and analysis details on Microchip's website, I can't remember.
(I've struggled getting proper FIT test descriptions so good luck :) )
 

Technical

Technical Support
Staff member
Statistically, yes, there is a good level of confidence this will be ok.

However the question is why so many writes, there may be a better solution. In particular remember you only need to write again if the data has actually changed.
 

jims

Senior Member
Statistically, yes, there is a good level of confidence this will be ok.

However the question is why so many writes, there may be a better solution. In particular remember you only need to write again if the data has actually changed.
Actually my number of writes will be extremely low. Will be entering control parameters for my controllers using an IR clicker and writing them to the on-board EEPROM. Parameters such as PWM duty values for LED light strings, ; Hi & Low temperature limits for temperature control; duration of pump ON/OFF cycles etc. These parameters will be changed infrequently (possibly no more than once per week). I certainly appreciate the good/rapid response from all of you. Jims
 

rq3

Senior Member
Statistically, yes, there is a good level of confidence this will be ok.

However the question is why so many writes, there may be a better solution. In particular remember you only need to write again if the data has actually changed.
Sorry to re-hash an old thread. Is there any reported "read disturb" effects in the PIC EEPROM? I have seen various and nebulous reports that repetitively reading an EEPROM cell can "reprogram" adjacent cells. Would a power on re-fresh of the EEPROM content help?

Thanks,
Rip
 

Dippy

Moderator
I have only had experience of corruptions due to power-errors-during-write and EEPROM endurance.

Microchip say that writing frequently to one section can degrade other locations in which case a read/re-write refresh of the array is beneficial.
Obv you will have to keep an eye on total writes.
On these occasions Microchip recommend storing fixed (and infrequently changed) values to Flash programme memory.

But reading causing corruption is new to me.
Can you provide a link to one or two of these "various and nebulous" reports as I have never heard of this before.
 

rq3

Senior Member
But reading causing corruption is new to me.
Can you provide a link to one or two of these "various and nebulous" reports as I have never heard of this before.
Hi Dippy. From what I've been reading, this applies to almost all forms of NV memory. Enter "read disturb" into your favorite search engine.
This should be pretty easy to test. I'll try it and see what happens.
Rip
 

srnet

Senior Member
From what I've been reading, this applies to NAND flash specifically, enter "read disturb" into your favorite search engine to find the wiki page.

Think about what you are suggesting, if the problem applied to all forms of NV Flash memory every PIC (which stores its program in NV\Flash memory) would fail very quickly, as the processor has to read locations in Flash all the time ...................
 

rq3

Senior Member
From what I've been reading, this applies to NAND flash specifically, enter "read disturb" into your favorite search engine to find the wiki page.

Think about what you are suggesting, if the problem applied to all forms of NV Flash memory every PIC (which stores its program in NV\Flash memory) would fail very quickly, as the processor has to read locations in Flash all the time ...................
Understood, srnet. What is the storage technology behind the read/write functions?
Rip
 

Dippy

Moderator
rq3, I think you'd better take this up with Microchip.
It's better to get information direct from them rather than rely on Google Regurgitation here.

All I can say is that I have never seen anything like this happen and, thanks for the education.
Some of the reports I have now glanced at can be a little ambiguous wrt flash-EEPROM and non-flash EEPROM.
So, Microchip support or website might be a good start.
 

rq3

Senior Member
rq3, I think you'd better take this up with Microchip.
It's better to get information direct from them rather than rely on Google Regurgitation here.

All I can say is that I have never seen anything like this happen and, thanks for the education.
Some of the reports I have now glanced at can be a little ambiguous wrt flash-EEPROM and non-flash EEPROM.
So, Microchip support or website might be a good start.
Agreed, Dippy. The Microchip App Notes 537,562,601, and 602 pretty much emphatically state that reading has no effect whatever on endurance. It's only during the erase/wite process that the EEPROM cells are subject to as much as 25 volts, which would be understandably stressful. In any case, I've written a short piece of crazy code to continuously read from four pre-loaded data EEPROM locations. If the LEDs go out, the test fails.

Thanks folks, as usual lots of food for thought here!
Rip
 

srnet

Senior Member
I wrote a bit of 'crazy' code specifically to check PICAXE EEPROM long term read stability for $50SAT.

Despite the somewhat harsh environment of a low Earth orbit satellite, no problems noted so far, but its only been 13 months.......................
 

rq3

Senior Member
Thanks for the support, Dippy. Microchip is VERY reticent to discuss their technology, as they should be. It appears that (for the 20M2 anyway),
the main chip (16F1829), has PEEC based FLASH memory for the program space. Interestingly, this technology also has lifetime limits, although
it's measured in decades or even centuries, and hundreds of millions of read/write sequences. However, it does wear out. Apparently, there are
methods of grabbing program code and re-installing it to fore-stall this effect, if you insist that your device still be functioning many decades from now.
The data EEPROM in the 20M2 is not so clearly defined. I could find very little data on it, but it appears to be fairly standard byte addressable NVRAM,
which most likely is vulnerable to the "read disturb" effect common to most EEPROM. Testing ongoing.
 

Buzby

Senior Member
PICAXE IN SPACE is the most impressive display of Microchip robustness I've ever seen.

13 months of wide temperature swings, plus all that cosmic ray stuff, and it's still going strong !.

( Great stuff, but even more amazing is that the battery is still working. )

I wouldn't worry about any EEPROM, ( or NVRAM ) problems in a 'normal' environment.

Merry Christmas,

Buzby
 

rq3

Senior Member
rq3, PIC EEPROM isn't Flash.... see you in a couple of years time :)
We need to be careful what we're talking about. The main program memory in the Picaxe 20M2 seems to be PEEC EEPROM.
It is indeed FLASH (hence the "F" in the Microchip 16F1829 base part number).
The data EEPROM in the same device is something else, and is likely vulnerable to the "read disturb" effect in poorly designed code.
 

rq3

Senior Member
PICAXE IN SPACE is the most impressive display of Microchip robustness I've ever seen.

13 months of wide temperature swings, plus all that cosmic ray stuff, and it's still going strong !.

( Great stuff, but even more amazing is that the battery is still working. )

I wouldn't worry about any EEPROM, ( or NVRAM ) problems in a 'normal' environment.

Merry Christmas,

Buzby
Picaxe in Space is indeed a truly impressive feat, and I certainly do NOT want to denigrate the effort. However, from an environmental aspect, it's actually fairly benign. During launch, the device might have seen, worst case, as much as 8 g acceleration, and maybe 20 g in shock broad spectrum (a rough rule of thumb is that a 5 g shock is dropping an object from 4 inches onto a concrete floor). Any decent printed circuit board can handle that on a one time basis. Once in low-Earth orbit, it's basically in a feather bed, gently cycling between perhaps -60C to +60C as it orbits. Perhaps out of the chip specified range, but nothing extreme, either. In low orbit, the radiation effects are certainly greater than at sea level on Earth, but let's not conflate NASA hysteria about the dangers of MANNED spaceflight with orbiting a circuit board. It's still operating well below the Van Allen belts, and all the UV effects we hear about on Earth, as carbon based units reliant upon an ozone layer are not applicable.

A digital board functioning for years on an off-road vehicle shuttling between the humid Mediterannean coast and the middle of the Sahara desert is in a much worse environment. The difference is the launch vehicle, and the wow factor of the end environment.

Assurances not to worry about something makes me worry :).

And Buzby, a very Merry Christmas to you and yours! Peace on Earth, and in Orbit.

Rip
 

rq3

Senior Member
I wrote a bit of 'crazy' code specifically to check PICAXE EEPROM long term read stability for $50SAT.

Despite the somewhat harsh environment of a low Earth orbit satellite, no problems noted so far, but its only been 13 months.......................
Which EEPROM? Program or data? When (not if) $50SAT fails, will you be able to tell what went wrong?

Rip
 

srnet

Senior Member
Which EEPROM? Program or data? When (not if) $50SAT fails, will you be able to tell what went wrong?

Rip
Both Program Flash and EEPROM have a read check.

Whilst a EEPROM read failure is benign, if the table (Flash) read fails it could stop working, but that could happen anyway, a read error in the middle of program code could obviously cause failure, and we may not hear about it.

The data we get back has a flags byte that indicates detected errors.
 

Dippy

Moderator
So, considering your actual code execution, how often is it reading a flash memory location?
How many Flash reads will srnet's device have done?
How often is it reading EEPROM?

srnet's project has demonstrated Flash and EEPROM (and RAM and registers and PC etc.) reliability in a relatively high radiation location - though we musn't confuse actual failure mechanisms here.
Srnet and team may not be able to tell us the cause of failure; was it simple random failure, or radiation induced failure or the elusive "read disturb" failure?

Anyway, I have learnt something new, but I think there are other more significant failure mechanisms to consider first.
Keep up the experiment... and I hope you'll be able to differentiate between "read disturb" and something else when it finally stops working :) .
 

hippy

Technical Support
Staff member
The data EEPROM in the same device is something else, and is likely vulnerable to the "read disturb" effect in poorly designed code.
There is however no evidence I can see for such a claim and it would surprise me if there was such a problem however the results of your testing will be interesting to see.

It is quite common to use EEPROM for lookup tables which are frequently accessed by code and I would have expected there to be some reports of this problem if reading specific bytes corrupted others.
 

srnet

Senior Member
I think there are other more significant failure mechanisms to consider first.
My thoughts too, so its odd a M2 is being used.

To protect against ram errors, program errors\bugs, power supply issues and similar, its real handy to have access to the processors reset pin.

So you would be using a 28X2 or 40X2 ?

Even in the 'benign' environment of low Earth orbit, I doubt $50SAT would have survived without access to the processors reset pin ..............
 

darb1972

Senior Member
Forgive me for butting in here but I have a question and find the subject of memory endurance very interesting.

In very simple terms.................

Would it be possible to write code that not only performed a checksum to ensure data integrity for a given location/s, but, if the headroom of spare memory existed, have the code shift to using a "fresh" area of memory and therefore avoiding a potential issue and/or extending the life of a project?

Sorry if that question seems too simplistic as I am only a novice when compared to the many code gurus on this forum. I was just interested and curious to know if this was feasible.
 

srnet

Senior Member
Feasible yes.

Remember the general rule of unforseen circumstances, by attempting to work around a problem (that may not exist!) you could introduce another problem that you did not forsee.
 

Dippy

Moderator
Not too simplistic at all. But not new.

Many flash memory controllers already spread it around.
I think the SD card controllers do it in an attempt to prolong 'cell' life.

And it is common practice where endurance is a problem in EEPROM.
I think Microchip have done an App Note on this, or where they suggest it.

Have a searcharound and I'm sure you'll see methods and suggestions.
 

darb1972

Senior Member
Thanks srnet/dippy. It makes for interesting conversation and research. I will have a search around on this forum and the web to find more on the subject.
 

geoff07

Senior Member
This practice was common in the microsats, where memory is 'washed' regularly to check for flipped bits and hard errors, which can then be worked around. But for that you really need error-correcting memory, i.e. with enough parity bits to tell you not only that you have an error, but where it is. Knowing that you have an error is helpful but unless you know which bit is the problem you can't recreate a clean version in a new location. It is a simple but clever technique, whereby the parity bits are located amongst the data and based on specific bit positions, such that when an error occurs the parity bits, read as a word, tell you the faulty bit position. You can simulate it in software, but you really need ECC hardware, as the error might be in the code that checks for errors.
 

darb1972

Senior Member
Thanks for the comments Geoff. Interesting stuff. I have somewhat dealt with parity bits but often see them neglected in programming. I will do some further research on the subject. I really enjoy reading this sort of information. It keeps the brain matter active.
 

rq3

Senior Member
So RQ3: Is your test program still running? Any read-disturb failures noted yet?
@bpowell
Nothing yet, and I really don't expect to see anything, per hippy above. If this were an issue, I'm sure it would have reared its ugly head long ago, but...
I figure after a week I will have done roughly 10 billion reads on EEPROM locations 28 through 39, which would represent several centuries of operation
of "proper code", where the EEPROM data is stuffed into RAM rather than being read continuously.
Just something that got my interest.
Rip
 

bpowell

Senior Member
These are always fun experiments... Keep us posted. Thanks.

Also, how long does your code take to do the read-and-verify loop? How did you calculate the 10 billion reads?
 
Top