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

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC uP EEPROM Array Refresh'
2004\12\30@150400 by Bob Axtell

face picon face
I've been busy but can now can examine the conversation and
data regarding EEPROM array refreshing. I looked at Microchip
site and downloaded several App Notes but none discussed
this (D120/D120A specs?).

Anybody have this information or links handy?

--Bob

--
Note: Attachments must be sent to
spam_OUTattachTakeThisOuTspamengineer.cotse.net, and
MAY delay replies to this message.
       520-219-2363

2004\12\30@152000 by Jan-Erik Soderholm

face picon face
> I've been busy but can now can examine the conversation and
> data regarding EEPROM array refreshing. I looked at Microchip
> site and downloaded several App Notes but none discussed
> this (D120/D120A specs?).
>
> Anybody have this information or links handy?
>

Hi.
Besides what's in the data sheets or what ?
I'm not sure what thread you are refering to, and the
subject seems to be new (?).

I can't remeber that any of the "EEPROM refresh" threads
lately ended with any open issues, did they ?

What does "this information" refer to ?

Best Regards,
Jan-Erik.



2004\12\30@160149 by Bob Axtell

face picon face
On a recent thread about 3 weeks ago, people were discussing the fact
that some PICs needed to have the EEPROM "refreshed" to maintain
data reliability. It appears to be a spec  only identified as D120 or D120A
and I can't locate it on the Microchip website.

I was busy at the time so missed the links. I'm asking if anybody has the
MC specifications for EEPROM array refreshing so I can understand the
issues involved.

As an example, on the Specs for the PIC12F675 (DS41190C) p #49,
paragraph  8.5.1 says "..specifications D120 or D120A." ...", and array
refresh must be performed". I am unable to locate specs D120 or D120A
on the Microchip Website, and I've located several App Notes that also
fail to mention an array refresh.

Ideas, anybody?

--Bob

Jan-Erik Soderholm wrote:

{Quote hidden}

--
Note: Attachments must be sent to
.....attachKILLspamspam@spam@engineer.cotse.net, and
MAY delay replies to this message.
       520-219-2363

2004\12\30@164212 by Jan-Erik Soderholm

face picon face
> On a recent thread about 3 weeks ago, people were discussing the fact
> that some PICs needed to have the EEPROM "refreshed" to maintain
> data reliability. It appears to be a spec  only identified as
> D120 or D120A and I can't locate it on the Microchip website.
>
> As an example, on the Specs for the PIC12F675 (DS41190C) p #49,
> paragraph  8.5.1 says "..specifications D120 or D120A." ...",
> and array refresh must be performed". I am unable to locate specs
> D120 or D120A on the Microchip Website,...

Now I'm realy confused. In my copy of the 12Fxxx data sheet (DS41190C)
D120-D124 are in table 12.7 on page 92.

Jan-Erik.



2004\12\30@175726 by Bob Axtell
face picon face
Jan-Erik Soderholm wrote:

{Quote hidden}

Oh, I see now. I guess I was concerned about nothing.

--Bob

--
Note: Attachments must be sent to
attachspamKILLspamengineer.cotse.net, and
MAY delay replies to this message.
       520-219-2363

2004\12\30@180619 by Hopkins

flavicon
face
Refer to page 89 table DC characteristics and you can see the
specifications listed in the left column.

_______________________________________
Roy
Tauranga
New Zealand
_______________________________________

> On a recent thread about 3 weeks ago, people were discussing the fact
> that some PICs needed to have the EEPROM "refreshed" to maintain
> data reliability. It appears to be a spec  only identified as
> D120 or D120A and I can't locate it on the Microchip website.
>
> As an example, on the Specs for the PIC12F675 (DS41190C) p #49,
> paragraph  8.5.1 says "..specifications D120 or D120A." ...",
> and array refresh must be performed". I am unable to locate specs
> D120 or D120A on the Microchip Website,...

Now I'm realy confused. In my copy of the 12Fxxx data sheet (DS41190C)
D120-D124 are in table 12.7 on page 92.

Jan-Erik.




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 30/12/2004


2004\12\30@184316 by Jan-Erik Soderholm

face picon face
Hopkins wrote :

> Refer to page 89 table DC characteristics and you can see the
> specifications listed in the left column.

Yes, there are some "specifications" on that page, mainly
"Supply current" under a number of different conditions.
But, in what way does they relate to the EEPROM refresh
issue ?
(And what's on page 92 in your copy of the data sheet ?)

Regards,
Jan-Erik.

{Quote hidden}

2004\12\30@190420 by Peter van Hoof

picon face
I dont get it either, you are supposed to do a refresh but
nothing in the datasheet tells you how often, or even how...
I do have an application out there on 12f629's  with one bit of
configuration data  (luckily non critical) but I do not have a
refresh built in.

doing a search on "refresh" on the microchip site does not give
me any usefull info, there is no info in the midrange manual.

Does anyone know the details?


Kind regards
Peter van Hoof


{Original Message removed}

2004\12\30@191926 by Jan-Erik Soderholm

face picon face
Peter van Hoof wrote :

> I dont get it either, you are supposed to do a refresh but
> nothing in the datasheet tells you how often,...

Yes it does (I assume we are still talking about the same device,
but I don't think it matters that much). Yes, it's a bit unclear, but
it's there.

>  or even how...

Some other data sheets has a short code example, but you simple
read and re-write each *used* EEPROM cell.

> I do have an application out there on 12f629's  with one bit of
> configuration data  (luckily non critical) but I do not have a
> refresh built in.

Check what the data sheet says about it and compare your number-
of-writes to those config data bytes (or is it realy just one *BIT* of
config data ??) with params D120-D124.

> Does anyone know the details?

If you point to a specific phrase or part of the data sheet
that you find unclear, we might help.

Regards,
Jan-Erik.



2004\12\30@201948 by Peter van Hoof

picon face
Stated in the 12f628 datasheet page 94 ,DC Characteristics:

D120 Byte Endurance 100K min 1M typ @-40-+85deg C
D120a Byte Endurance 10K min 100K typ @+85-+125deg C
D124 Number of Total Erase/Write Cycles before refresh, 1M
min 10M typ E/W See Section 8.5.1 for additional information

8.5.1 USING THE DATA EEPROM

The Data EEPROM is a high-endurance, byte addressable array that
has been optimized for the storage of frequently changing
information (e.g., program variables or other data that are
updated often). Frequently changing values will typically be
updated more often than specifications D120 or D120A. If this is
not the case, an array refresh must be performed. For this
reason, variables that change infrequently (such as constants,
IDs, calibration, etc.) should be stored in FLASH program memory.

The way I understand this:

>From section 8.5.1 If I do not erase/write more than at least 10K
cycles (per what I dont know) I have to refresh the data

>From D124 I get that I can erase/write at least 1M times before
having to do a refresh ????????

I JUST DONT GET IT..........

Kind regards
Peter van Hoof




{Original Message removed}

2004\12\30@205630 by Robert Rolf

picon face
The EEPROM switches used to drive the array are not perfect
and have some minute leakage. If you write to the array enough times,
the accumulated leakage pulses can cause the stored charge in a cell
to shift enough that you don't get a reliable read back.

If you write to EEPROM more than D124 times (1 Million- 10 million,
depending on temperature) you need to refresh ALL the EEPROM data to
ensure it's long term integrity.

What's to NOT understand?
Write to EEPROM more than a million times and you need
to refresh the data (read then writeback) if you have
values that have NOT been rewritten in a million cycles.

R

Peter van Hoof wrote:

{Quote hidden}

> {Original Message removed}

2004\12\30@205857 by Jason Harper

picon face
> I JUST DONT GET IT..........

D120 is the number of times any one EEPROM cell can survive being
written to.  Once it's exceeded, that one cell may be permanently
damaged, and not reliably read the data last written to it.

D124 is the number of times any one cell can survive writes to OTHER
cells.  The high voltage involved in erasing a cell leaks a little, and
erases all the other cells about one millionth of the way.  Once this is
exceeded, the cell may not read back the previously written data
correctly, but it can still be written to (either with new data, or
refreshed with the existing data) as long as its D120 limit hasn't been reached.

Writing to any cell will:
* add one towards that cell's D120 limit.
* reset that cell's D124 limit.
* add one to all other cells' D124 limit.
       Jason Harper

2004\12\30@222008 by csb

flavicon
face
> If you write to EEPROM more than D124 times (1 Million- 10 million,
> depending on temperature) you need to refresh ALL the EEPROM data to
> ensure it's long term integrity.
So they'll last 'forever' if refreshed and kept under normal conditions?
I thought 1M-and-then-no-more was a bit weird.

Christian

2004\12\30@222617 by Bob Ammerman

picon face
This should be written up as a FAQ at piclist.com (is it already there?)

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.

hth

Bob Ammerman
RAm Systems




2004\12\30@223928 by Bob Axtell

face picon face
Hi Peter,

I always write configuration data in 3 places.

Here is what I do routinely when I want to use EEPROM data
(been doing it for several years now):

1. Read all three instances of the data. Compare each against each.
If all 3 match, you are fine. If any two match, rewrite the 3 instances
using good data from the good two, verifying the write in each case.

2. If all 3 are somehow bad , use default values and post an error (if
you can). I've never found all 3 instances to be bad, but this is possible,
so it is used.

This is MY method. Never a complaint from  clients, so I guess its
OK.

NOTE: if the application requires a LOT of reads and writes, I use a
RAMTRON device, not the EEPROM device.

I've decided that I just got confused with the paragraph.

Years ago, I'd gotten indications from a friend that when Microchip
started with their flash chips that the EEPROMs were NOT as good
as they were when the chips were UV eraseable, hence the procedure.

--Bob


Peter van Hoof wrote:

{Quote hidden}

> {Original Message removed}

2004\12\31@001959 by Peter van Hoof

picon face
Thank you all for the clarifications, clear as a bell now . From
what I read in the paragraph in the datasheet I was wondering if
my application was in any danger of losing  any data.

Since the only user changable option is set by holding a button
down for 10 seconds while powering up (toggle on / off) and only
writes to one byte I hardly think I have anything to worry about.

thanks again
Peter van Hoof


2004\12\31@055314 by Jan-Erik Soderholm

face picon face
csb wrote :

> > If you write to EEPROM more than D124 times (1 Million- 10 million,
> > depending on temperature) you need to refresh ALL the EEPROM data to
> > ensure it's long term integrity.
>
> So they'll last 'forever' if refreshed and kept under normal
> conditions?

No. Absolutly not !
Why on earth do you think that ??

The "max-write-to-each-single-cell" is still valid.
See paramater D120 in most (all?) data sheets.

So even if refreshed, you can not refresh a specific
EEPROM cell more time then the D120 paramater says.
A refresh is just a normal write and counts againts D120.

> I thought 1M-and-then-no-more was a bit weird.

Why did you think it was weird ?

D120 "Byte Endurance" = max writes for a single cell.
Is there *anything* unclear there ?

(The "refresh issue" is another question and maybe a little more
unclear, but not at all impossible to understand...)

Jan-Erik.

PS:
If you with "forever" mean something else then *forever*,
then we have another case of course. But then, you must tell us
when "forever" meens to you...



2004\12\31@112952 by csb

flavicon
face
> The "max-write-to-each-single-cell" is still valid.
> See paramater D120 in most (all?) data sheets.
>
> So even if refreshed, you can not refresh a specific
> EEPROM cell more time then the D120 paramater says.
> A refresh is just a normal write and counts againts D120.
>
> > I thought 1M-and-then-no-more was a bit weird.
>
> Why did you think it was weird ?
Because I didn't know EEPROM actually died. Plus, the fact that a
logger that writes data to EEPROM every second will die in a few days.

I hadn't read the paragraph you cited (who wrote it? It seems I don't
have that post).
I thought you needed to refresh a frequently used cell every D120
cycles, and any less-used cells (that are affected during writes
to other cells) every D124, and doing a refresh would reset both
counters. It would've been nice.

That was my inexperience speaking. Thanks for clarifying this, I
never would've thought it was such a problem.

Christian

2004\12\31@115042 by Jan-Erik Soderholm

face picon face
> > The "max-write-to-each-single-cell" is still valid.
> > See paramater D120 in most (all?) data sheets.
> >
> > So even if refreshed, you can not refresh a specific
> > EEPROM cell more time then the D120 paramater says.
> > A refresh is just a normal write and counts againts D120.
> >
> > > I thought 1M-and-then-no-more was a bit weird.
> >
> > Why did you think it was weird ?

> Because I didn't know EEPROM actually died. Plus, the fact that a
> logger that writes data to EEPROM every second will die in a few days.

As others have said, there are other ways to deal with that.
- Use Ramtron devices.
- Use standard RAM and copy to the EEPROM on a power loss (must
 have power loss detection and some caps or batteries to power the
 PIC during the EEPROM write).

> I hadn't read the paragraph you cited (who wrote it? It seems I don't
> have that post).

I'm not sure anymore what paragraph that was.

> I thought you needed to refresh a frequently used cell every D120
> cycles,...

Since a "refresh" is nothing but a normal write, a "frequently used cell"
would *never* have to be refreshed, by definition.

> and any less-used cells (that are affected during writes
> to other cells) every D124,...

Right.

> and doing a refresh would reset both counters. It would've been nice.

The D120 counter (the "max writes" counter) is incremenet for each
individual cell at each write, no matter if it's a normal "application
write"
or a "refresh write". And it's never reset, just as you said.

The D124 counter is incremented for each used cell whenever *another*
cell is written. It's reset on refresh (or an "application write", of course).

> That was my inexperience speaking. Thanks for clarifying this, I
> never would've thought it was such a problem.

There is definitly a need of some kind of "whate paper" on this issue :
-)

Happy New Year !
Jan-Erik



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