Searching \ for '[PIC] EEPROM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/memory.htm?key=eeprom
Search entire site for: 'EEPROM'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] EEPROM'
2006\04\16@123440 by Przemyslaw Lopaciuk

picon face
Any idea, how many times can PIC's EEPROM cell be written to? ( I'm
using PIC18F8621 ).



Best regards,

Sam  

2006\04\16@130239 by olin piclist

face picon face
Przemyslaw Lopaciuk wrote:
> Any idea, how many times can PIC's EEPROM cell be written to? ( I'm
> using PIC18F8621 ).

RTFM!

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\04\16@133701 by blackcat

face picon face
0000000000

I respectfully ( i think ) request that responses
such as RTFM! be eliminated.  Not because of the words,
because of the violence of the response.  Or use lower case
with some endearment.
rtfm .... my dear boy

Gus
00000000000


On 2006-Apr 16, at 11:02 AM, Olin Lathrop wrote:

Przemyslaw Lopaciuk wrote:
> Any idea, how many times can PIC's EEPROM cell be written to? ( I'm
> using PIC18F8621 ).

RTFM!

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\04\16@134231 by Jan-Erik Soderholm

face picon face
Przemyslaw Lopaciuk wrote :

> Any idea, how many times can PIC's EEPROM cell be written to? ( I'm
> using PIC18F8621 ).


I'm pretty sure that the datasheet knows...

Jan-Erik.



2006\04\16@135103 by Przemyslaw Lopaciuk

picon face
Datasheet does say that it is 1mln times.
I'm not asking about what datasheet says but I'm asking if anybody had
encountered any problems with writing for example more than 900 000
times to one cell.
Is that 1mln times a "safe" number.

Best regards,
Sam



-----Original Message-----
From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On Behalf
Of Jan-Erik Soderholm
Sent: 16 April 2006 18:43
To: piclistspamKILLspammit.edu
Subject: RE: [PIC] EEPROM

Przemyslaw Lopaciuk wrote :

> Any idea, how many times can PIC's EEPROM cell be written to? ( I'm
> using PIC18F8621 ).


I'm pretty sure that the datasheet knows...

Jan-Erik.



2006\04\16@141623 by Jan-Erik Soderholm

face picon face
Przemyslaw Lopaciuk wrote :

> Datasheet does say that it is 1mln times.

Fine then !

> I'm not asking about what datasheet says but I'm asking if anybody
had
> encountered any problems with writing for example more than 900 000
> times to one cell.

Maybe, but that could be some "user error", and not be rellevant
for your application anyway.

> Is that 1mln times a "safe" number.

That,s why it's there.
Also check the errata sheets for your processor.

And also read about "refresh" of the EEPROM. (Important !)

Jan-Erik.



2006\04\16@144246 by Bob Axtell

face picon face
Przemyslaw Lopaciuk wrote:
> Any idea, how many times can PIC's EEPROM cell be written to? ( I'm
> using PIC18F8621 ).
>
>  
>
> Best regards,
>
> Sam  
>
>  
You will get a LOT of different replies.

My opinion is that the newer PICs have a more fragile EEPROM system than
that of the non-
flash PICs. I have had several clients that indicated data losses in
only a few weeks of time.
The best solution is to avoid EEPROM altogether (Use RAMTRON devices)...
but people
won't or can't do that, so here is the next-best thing: when you write a
variable, write it in 3 places.
Then when you read it, use "best 2 of 3" algorithm, noting that if one
of the 3 is wrong, rewrite it.

I've never seen this fail again.

--Bob

2006\04\16@173626 by Jinx

face picon face
> Datasheet does say that it is 1mln times.
> I'm not asking about what datasheet says but I'm asking if anybody had
> encountered any problems with writing for example more than 900 000
> times to one cell.
> Is that 1mln times a "safe" number.

**** Please **** ask the **** real **** question the first time eh ?

Everything a System Engineer Needs to Know About Serial
EEPROM Endurance

http://ww1.microchip.com/downloads/en/AppNotes/00537.pdf

EEPROM Endurance Tutorial

http://ww1.microchip.com/downloads/en/AppNotes/00601.pdf

Using the Microchip Endurance Predictive Software

http://ww1.microchip.com/downloads/en/AppNotes/00562.pdf

Endurance

http://ww1.microchip.com/downloads/en/DeviceDoc/end240.zip

Total Endurance Software Download

http://ww1.microchip.com/downloads/en/DeviceDoc/totend40.zip

"Microchip's New Total Endurance Disk Provides An Innovative
Tool For Predicting Application Life Of Serial EEPROMs"

http://ww1.microchip.com/downloads/en/DeviceDoc/061193.doc


2006\04\16@174715 by olin piclist

face picon face
blackcat wrote:
> I respectfully ( i think ) request that responses
> such as RTFM! be eliminated.  Not because of the words,
> because of the violence of the response.  Or use lower case
> with some endearment.
> rtfm .... my dear boy

RTFM is a standard response on the internet.  You obviously knew what it
meant.  It is reserved for questions where it is clear the poster hadn't
even bothered to look in the obvious place where one would expect to find
the information.  Note that this question was not about interpretation of
the spec or where the spec might be found, it was simply "give me an
answer", where the answer was spelled out directly in the data sheet right
about where you'd expect to find it.  I don't see any reason for a gentle
response to something this blatant.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\04\16@180416 by Jinx

face picon face
> My opinion is that the newer PICs have a more fragile EEPROM
> system than that of the non-flash PICs. I have had several clients
> that indicated data losses in only a few weeks of time

Hi Bob, any specifics regarding that ? A Microchip advisory for
example ?

2006\04\16@195243 by Bob Axtell

face picon face
Jinx wrote:
>> My opinion is that the newer PICs have a more fragile EEPROM
>> system than that of the non-flash PICs. I have had several clients
>> that indicated data losses in only a few weeks of time
>>    
>
> Hi Bob, any specifics regarding that ? A Microchip advisory for
> example ?
>
>  
No, alas. I have a history of EEPROM during the PIC16C days, and now
during the PIC16F
days. No question about it, the process is simply less reliable. I think
MicroChip knows it, too,
because it has a LOT of notes about it. They won't formally announce a
problem because MOST
people rewrite their data  in a manner that makes them not notice it.

My clients who in the past used PIC16C devices with almost no failures
exhibit many failures now
after switching to newer, less costly PIC16F devices. I have corrected
all of their problems
with the "best two of three" scheme, which not only provides reliable
data, it tells me when I
need to rewrite a byte.

Why? I have no idea. Should I care? No, because MicroChip stood by me
when the s _ _ _
hit the fan after the Motorola debacle, I will stand by MC while they
figure out what the problem
is here. MC could be afloat with a broken oar during Katrina and I'd
stand by 'em.

Hint: The MicroChip 16K/32K/65K EEPROM arrays are NOT afflicted by this
malady.

It gets noticed first by customers who perform self-tests on PICs. The
way to notice it is to
write pseudorandom data to the EEPROM array then perform a CRC16 test on
the entire
array. The estimated failure rate should be at least a year of constant
patterns without an
error, but you will notice failures long before that.

--Bob

2006\04\16@224521 by blackcat

face picon face
I guess that means it is okay for me to respond in
kind.......
YAAFIAIASSOAAWTTTCMTGQED

Gus


On 2006-Apr 16, at 3:47 PM, Olin Lathrop wrote:

blackcat wrote:
> I respectfully ( i think ) request that responses
> such as RTFM! be eliminated.  Not because of the words,
> because of the violence of the response.  Or use lower case
> with some endearment.
> rtfm .... my dear boy

RTFM is a standard response on the internet.  You obviously knew what it
meant.  It is reserved for questions where it is clear the poster hadn't
even bothered to look in the obvious place where one would expect to  
find
the information.  Note that this question was not about  
interpretation of
the spec or where the spec might be found, it was simply "give me an
answer", where the answer was spelled out directly in the data sheet  
right
about where you'd expect to find it.  I don't see any reason for a  
gentle
response to something this blatant.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\04\16@234342 by Jinx

face picon face

> YAAFIAIASSOAAWTTTCMTGQED

I am SO glad my mother didn't see that

2006\04\16@235016 by Peter Todd

picon face
On Sun, Apr 16, 2006 at 04:52:36PM -0700, Bob Axtell wrote:
> It gets noticed first by customers who perform self-tests on PICs. The
> way to notice it is to
> write pseudorandom data to the EEPROM array then perform a CRC16 test on
> the entire
> array. The estimated failure rate should be at least a year of constant
> patterns without an
> error, but you will notice failures long before that.

That's scary... I've got 4 projects right now with EEPROM hours meters.
3 based on 18F242 chips (one 12F675) Every hour they read a fixed value
from the EEPROM, add one, and write it back. They also do similar things
when knobs are turned.

Which means... That after 10 years I'm counting on 87,600
read-modify-write sequences to happen perfectly. Unfortunately didn't
think to do the best of three when I wrote the code, or rotate memory
locations.

So are 18F chips affected too? 12F? What's your estimated failure rate
anyway?

Oh well, probably have to get the programmer out and fix the firmware on
them. Too bad the 12F project is very securely potted in epoxy. :)

--
.....peteKILLspamspam.....petertodd.ca http://www.petertodd.ca

2006\04\17@003203 by Bob Axtell

face picon face
Peter Todd wrote:
{Quote hidden}

Once an hour? THAT's not tough. You might be all right. I'm talking
about almost constant
changing.

> So are 18F chips affected too? 12F? What's your estimated failure rate
> anyway?
>  
99% of my projects are PIC16F, so I'm not sure. My guess is that it is
the semiconductor PROCESS that has the
problem, NOT the PIC#. I do this routinely now.

> Oh well, probably have to get the programmer out and fix the firmware on
> them. Too bad the 12F project is very securely potted in epoxy. :)
>
>  
well, at least there IS a fix.

--Bob


2006\04\17@053320 by Wouter van Ooijen

face picon face
> I guess that means it is okay for me to respond in
> kind....... YAAFIAIASSOAAWTTTCMTGQED

Your search - YAAFIAIASSOAAWTTTCMTGQED - did not match any documents.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\04\17@093538 by Peter Todd

picon face
On Sun, Apr 16, 2006 at 09:31:40PM -0700, Bob Axtell wrote:
> > Which means... That after 10 years I'm counting on 87,600
> > read-modify-write sequences to happen perfectly. Unfortunately didn't
> > think to do the best of three when I wrote the code, or rotate memory
> > locations.
> >  
> Once an hour? THAT's not tough. You might be all right. I'm talking
> about almost constant
> changing.

Thanks, that's reassuring. I went with the simple scheme in the first
place because my once per hour requierment seemed pretty lightweight to
me.

Oh well, writing the full write-balancing, array refreshing,
fault-tolerent, monster of a eeprom hour meter will be on my todo list
all the same.

> > So are 18F chips affected too? 12F? What's your estimated failure rate
> > anyway?
> >  
> 99% of my projects are PIC16F, so I'm not sure. My guess is that it is
> the semiconductor PROCESS that has the
> problem, NOT the PIC#. I do this routinely now.

You're probably right. Given that the 16F's and 18F's operate at the
same clock speeds, I'd assume they are the same process too. But then
again, I only play a semiconductor designer on TV.

--
EraseMEpetespam_OUTspamTakeThisOuTpetertodd.ca http://www.petertodd.ca

2006\04\22@030555 by Jinx

face picon face
oase.uci.kun.nl/~mientki/pic/libs_hw/eeprom_problems.html

EEprom endurance

Introduction

In December 2004 an interesting discussion took place about an often
overseen spec of the EEprom.

I too have done a project that has probems probably due to this phenomenom

I even have written a library to increase the EEprom endurance, by spreading
the information over the complete EEprom, but which offences against this
rule
and make things probably worse.

What's the problem ?

Normal endurance (parameter D124) is worst case 10^6 (upto 85 Celcius).
But writing to some place in EEprom, reduces the endurance of the other
EEprom locations by a factor 10, (parameter D120) up to 85 Celcius a
factor of 100, (parameter D120A) above 85 Celcius

So my conclusion is that I've to write a new library, not spreading the
information over the EEprom, but keeping the number of writes into a
counter and create a refresh of the total EEprom when counter exceeds
a certain value.

from m'chip techsupport

The data sheet is being updated in this area.
The refresh works as follows:
Any individual EEPROM cell has an absolute maximum endurance.
If you extend the endurance of a piece of data by spreading the value
across a few cells you can increase the data's endurance by n *
endurance, where n is the number of cells you spread the value across.

If you are updating the entire EEPROM array but you have a few cells
that never get touched, the data can be disturbed if the rest of the array
has had 10Million erase cycles performed anywhere in the array.

Refresh means you read and re-write the little used cells before the entire
array sees 10Million writes.

The ultimate endurance of the DATA EEPROM memory is (size * cell
Endurance). However if you never touch one address you can expect that
one address to be corrupted before you reach the ultimate endurance.

That is why we recomend periodic refresh of less frequently used memory
locations.

from Bob Ammerman:

Basically the issue is this:

Any write to EEPROM memory (any location) degrades the signal stored
in _all_ EEPROM locations. Thus, the value of any given location can be
corrupted, if there are too many writes to _other_ locations between writes
to that location.

The datasheet will define parameters for this. For many, but not all PICs,
these parameters are called D120 and D120A.
For an example, looking at the datasheet for the PIC18F1220/PIC18F1320
we find (marked as advance information in the copy I have):
Parameter D120 - Byte Endurance - Min=100K, Typ=1M -- This is the
number of times any single byte of EEPROM can be written to reliably.
Parameter D124 - Number of total ERASE/WRITE cycles before refresh -
Min = 1M, Typ = 10M -- Any bytes that have _not_ been written need to
be refreshed before D124 total writes to other bytes are done.

So, what does this really mean?

Well, if you do less than 1M total writes to the EEPROM (and 100K to
any one byte) in the life of your product, you have no problem.

If you are using some sort of logging scheme where every EEPROM cell
you are using is written to 'regularly', you have no problem.

The typical case where you do have a problem is where some EEPROM
locations are quite static and seldom written, while others are actively
written. A primary example of this is where configuration or calibration
data
is stored in part of the EEPROM and logged data in the rest. In this case
you would have to perform a periodic refresh of the
configuration/calibration
data (before doing 1M writes to the logging data area).

A refresh, of course, is as simple as reading and then immediately rewriting
the same memory location with the same value.

One useful way to avoid the refresh issue is to store your configuration/
calibration data in program memory on those PICs that support self writing.
This will work if you can live within the endurance constraint of program
memory (parameter D130 for our example PICS, Min=10K, Typ=100K), and
can afford to have your PIC 'freeze' while writing the parameters

2006\04\22@081534 by Howard Winter

face
flavicon
picon face
Interesting stuff, Jinx, but:

On Sat, 22 Apr 2006 19:05:50 +1200, Jinx wrote:

> One useful way to avoid the refresh issue is to store your configuration/
> calibration data in program memory on those PICs that support self writing.
> This will work if you can live within the endurance constraint of program
> memory (parameter D130 for our example PICS, Min=10K, Typ=100K), and
> can afford to have your PIC 'freeze' while writing the parameters

But doesn't this mean you're using something which has 1/10th of the endurance (10k/100k vs. 100k/1M)?  And
does program memory suffer the same "rewrite of something degrades the rest" problem of data EEPROM?  Surely
if it does, you're better using EEPROM since it has ten times the endurance to start with?  (OK, I'll stop
calling you Shirley! :-)

Cheers,


Howard Winter
St.Albans, England


2006\04\22@092301 by Jinx

face picon face
> But doesn't this mean you're using something which has 1/10th of
> the endurance (10k/100k vs. 100k/1M)?  And does program
> memory suffer the same "rewrite of something degrades the rest"
> problem of data EEPROM?

Hmmm, good question. I'm guessing NOR-based, but Microchip
may use something completely different

From

http://www.linuxdevices.com/articles/AT4422361427.html

"Maximize media lifespan -- When some blocks of memory contain
fixed content, such as binary code, the remaining blocks will experience
increased demand for erase and write operations, leading to earlier
failure. Wear-leveling algorithms can prevent overuse of memory blocks
and prevent a "stalemate" scenario in which a small region of memory
becomes locked in a pattern of repeated writing and compaction. Wear
leveling software can monitor block usage to identify high-use areas and
low-use areas containing static data, then swap the static data into the
high use areas. It can also balance write operations across all available
blocks by choosing the optimal location for each write operation"

>  Surely if it does, you're better using
> EEPROM since it has ten times the endurance to start with?  (OK,
> I'll stop calling you Shirley! :-)

"Joey, do you like gladiator movies ?"

Well, Betty, I think the point being made was to store static or
infrequently-written data outside of EEPROM so that it doesn't
get corrupted by all the other EEPROM writing.

"The typical case where you do have a problem is where some
EEPROM locations are quite static and seldom written, while others
are actively written. A primary example of this is where configuration
or calibration data is stored in part of the EEPROM and logged
data in the rest. In this case you would have to perform a periodic
refresh of the configuration/calibration data (before doing 1M writes
to the logging data area)"

However you use EEPROM, it behooves you to know how each
location will be used and affected

2006\04\24@111400 by Bob Axtell

face picon face
Jinx, I still think that this overall refresh idea leaves a lot to be
desired, since there is a
maximum erase/write lifetime in any case, and, that while they are
interesting, they
do NOT guarantee reliable EEPROM data.

I have read all the notes and explanations by Microchip, and have
arrived at this fix:
I believe the best overall solution is to use a "best of 3" algorithm,
refreshing only those
cells that actually need it. I believe this because of the bathtub
curve.. in some chips, the
overall refresh will occur too late; in most others it will occur too
soon. Best of three (or
for VERY infrequent data, best of 5) does the job with a minimum of
wasted effort, and
considers more possibilities (temperature, voltage, etc).

--Bob

Jinx wrote:
{Quote hidden}

2006\04\24@180821 by Jinx

face picon face

> I believe the best overall solution is to use a "best of 3" algorithm,
> refreshing only those cells that actually need it

Agree. No matter what someone says should maximise life, the
data is what's important

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...