limitation on number of EPROM read/write cycles?

J

John Chris

Senior Member
Hi there,

I am wondering if anyone has any idea if there is a specified maximum number of EPROM read/write cycles?

I have developed a 'WaitForTime' subroutine that writes the time obtained from an RTC to eprom roughly 4 times a second. It checks the current time against a set time that is also stored in EPROM. The subroutine is designed to be valid for durations of hours, days, weeks, etc. This adds up to a large number of read/write cycles. If the on-chip EPROM has a finite life span, then this approach would seem to be a lousy one.

Any comments / suggestions are greatly appreciated.

Thanks,

Chris
 
Last edited by a moderator:
B

BeanieBots

Moderator
You can read as often as you like but writes have a limited life-span.
How many depends on which device you are using.
The worst case is as low as 10,000 but usually 100,000 or 1 million.
 
M

MPep

Senior Member
You would need to read the specific datasheet for the device in mind. If it is PICAXE, the 'raw' part numbers are listed in the 1st PICAXE manual. Then search on the Microchip website.
 
D

Dippy

Moderator
Exactly. Don't guess or assume - read it from the PIC Data Sheet.

For all electrical/performance data always go to the actual PIC Data Sheet (and sometimes the errata sheet).

PS. Don't forget that these endurance figures usually relate to Erase/Writes to a cell or block. So, with a bit of cunning planning you can write to different areas so that you effectively prolong the life. i.e. don't keep rubbing away at the same place, spread it around.
 
Last edited:
D

Dippy

Moderator
Interesting.... so, based on that, we should assume that all EEPROM (/Flash*) will last that long?
11 million for all types of EPPROM in all types of PIC? Oh Dear...

Go to Microchip site and read the documentation on Endurance testing.

All these failures will be STATISTICAL in nature.
When Microchip put in miniumum figures, for example, these will be based on figures taken from a set of devices. And a statistically acceptable figure for minimum and typical will be found.

I think it was DPG who did a few tests on a particular PICAXE EEPROM. From memory (haha) I think he got figures around 3million when writing to a particular location.
So, for goodness sake, don't rely on figures that someone has obtained with a sample of 2 or 3.

*Note. This should get a few hits for Google....
 
slimplynth

slimplynth

Senior Member
:) I was trying to post that link too last night obroni.. found it through Hackaday.com but mi blackberry was refusing to post to the forum.

Quickly read through it in bed... personally thought it was a well written intro to eeprom.

(Dippy - I think it does cover the issue of different eeprom types and manner of use i.e. slow writes vs. megaquick 'burst' writing. they state the max write cycles for a few models.. think the main purpose though is to encourage people to have a try - the kit costs $30 dollars - i think)
 
D

Dippy

Moderator
Fair enough.
Personally, I'll stick to Microchip's documentation and test methods/results.
- and save paying $30 for something I'd use once and then bin.:rolleyes:

Anyway, the answers to most questions like this are on the Microchip site.
 
J

John Chris

Senior Member
Thanks for all the comments. I will look into this for the specific device that I am using.

Regarding the timing subroutine. Can anyone nominate an elegant way to suspend or pause an application for hours, days, week, while doing so with seconds resolution?

I assume that the scratchpad also possesses a finite life span ?

Chris]
 
Last edited by a moderator:
M

MartinM57

Moderator
Regarding the timing subroutine. Can anyone nominate an elegant way to suspend or pause an application for hours, days, week, while doing so with seconds resolution?
Click to expand...
One proper way would be to use a crystal controlled RTC chip (as you mention 'second accuracy' in conjunction with 'week') with a programmable alarms. This sort of RTC is one step above the normal DS1307 etc - google for M41T94 for example.

The (simplified) strategy would be:
- connect the RTC alarm pin to a PICAXE interrupt pin
- set the programmable alarm to the time when you next want to wake up
- use the hibernate command (see Manual 2) to go to sleep until the interrupt occurs
- service the interrupt as required

I assume that the scratchpad also possesses a finite life span?
Click to expand...
No, the scratchpad is in RAM and has (effectively) infinite life.
 
B

BeanieBots

Moderator
Scratchpad is RAM and can be written to as often as you like.

Not sure I understand your dilema with waiting a period of time.
I thought you had a RTC chip?
Just wait for a specific time and/or X seconds to pass.
 
M

MFB

Senior Member
Anyone concerned about EEPROM life should consider pin compatible FRAM for non-volatile applications. More costly and lower capacity than EEPROM, but is faster and has unlimited number of read-write cycles.
 
M

MartinM57

Moderator
Just to be a pedant....a typical FRAM chip (RAMTRON FM25640) has:
· 10 Billion (10^10) read/writes
· 10 year data retention at 55° C
· No write delay i.e. you can write to it as fast as your SPI bus will run.
 
hippy

hippy

Technical Support
Staff member
10 billion sounds much like "infinity" to most people, and if accessed once a second it amounts to over 300 years of life, but if accessed every millisecond it is only four months. In most cases access is not that frequent and it would likely suffice.

The interesting thing is that it genuinely is read and write access which wears it out, not just erase-write with infinite reads. That too shouldn't be a problem in most cases but a design which repeatedly read 'external Eeprom' in a tight loop could come unstuck.

Latest datasheet on the FM25640 shows 1 trillion read/write operations; 30 years of life even if accessed every millisecond. Reading revision history suggests that applies to all FM25640's since production started.
 
M

MartinM57

Moderator
Ooh...must spend this evening updating my locally held datasheets - there I was thinking the FM2560 only does 10^10 writes, but it does 10^12 (mind you, how many do the two I've had in a tube for 18 months do?)
 
D

Dippy

Moderator
Test them to destruction using the FlashZapper and then you'll know.
It's always interesting to duplicate work already done and waste time&money :rolleyes:
 
J

John Chris

Senior Member
BeanieBots said:
Scratchpad is RAM and can be written to as often as you like.

Not sure I understand your dilema with waiting a period of time.
I thought you had a RTC chip?
Just wait for a specific time and/or X seconds to pass.
Click to expand...
Somewhat delayed ...

I am using the DS1388 RTC. My issue is simply with the mechanics of what you suggest above. Here is the pseudocode for a subroutine that I have developed:

- get time from RTC
- write 6-element time vector (returned from RTC) to EPROM at position specified by pointer 'current_time_pos'
- compare to 6-element time vector starting at postiion 'current_time_pos' to time vector corresponding to a given setpoint.
- if all elements in current time and setpoint are equal then exit subroutine, other wise pause for less than half a second and repeat.

Here is the actual code for those who might see way to improve it:

WaitForTime:
' Argument: strtpos1 - a pointer to a future time vector
' Functionality: Continuously check future time against current, exiting loop when current = future
' Seconds resolution, Nyquist frequency sampling (twice or better per second)
DO
LET istime = 1
GOSUB GetDateAndTime
FOR counter_a = year_offset_eprom TO second_offset_eprom
LET position1 = current_time_pos + counter_a
LET position2 = strtpos1 + counter_a
READ position1,temp1
READ position2,temp2
IF temp1 != temp2 THEN
LET istime = 0
ENDIF
NEXT counter_a
PAUSE t_wait_for_time
LOOP WHILE istime = 0
RETURN

Thanks,

Chris
 
Last edited by a moderator:
W

westaust55

Moderator
Presuming that you do have some valid reason, such as insufficient variables, requiring that you save the time data, then consider the RAM locations within the SFR or on X1/X2 parts the scratchpad memory as alternatives to EEPROM. The RAM/Scratchpad can be written to as often as you like but obviously not retained in the event of a loss of power supply.


EDIT: and looking at your other thread, I see that
- you are using a 28X2
- others have also suggested scratchpad memory as well.
Really would be good to keep similar questions on a single project in one thread – avoids others having to jump back and forth.
 
Last edited:
B

boriz

Senior Member
"Exactly. Don't guess or assume - read it from the PIC Data Sheet." Coz theyz always completely accurate innit. Empiricals notwithstanding brov.
 
D

Dippy

Moderator
Oh oh, Boriz is on a mission .... I love the irony :)
I'd sooner have experimental facts rather than empirical - sources tend to be more reliable.

"Accuracy" and statistics are strange bedfellows in my opinion.

However, on a serious note:-
A) Microchip have the resources and trained expertise.
B) They can afford to test many examples, so their experimental measurements are FAR more statistically significant than anyone could do here.
C) Microchip can afford to test and provide results from different batches. Little Frankie couldn't afford to do this and report anything of significance back to the PICAXE collective.

Microchip also provide information on their testing methods and criteria.
They (usually, not always) provide 'minimum' and 'typical' values - obviously these will have statistical boundaries as, in the real world, 'minimum' is zero.

If brave enough it is actually possible to get the information from Microchip - they tend not to send a hit-squad around for asking a question.


So, if anyone can provide better figures than Microchip (errata accepted) then please post it here, innit. I would be genuinely interested to see it, as EEPROM endurance has been an issue with some of my own recent projects.
Typoes withstanding brov ;)
 
You must log in or register to reply here.
Top