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

Exact match. Not showing close matches.
PICList Thread
'[PIC]: EEPROM Data Retention'
2009\05\05@045402 by pic.list

picon face
specification of eeprom data retention looks a bit weird to me (18F2525 datasheet).


in the eeprom section, i find:

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 specification D124. 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. A simple data EEPROM refresh routine is shown in
Example 7-3.
Note: If data EEPROM is only used to store constants and/or data that changes often, an array refresh is likely not required. See specification D124.


this looks like i have to do a refresh if i do not rewrite eeprom data more often than specified under D124.


when i go to the timing section, i find:

D124 TREF Number of Total Erase/Write Cycles before Refresh > 1M
D123 TRETD Characteristic Retention > 40 Year


this specification tells me that i need to do an eeprom refresh after rewriting data more than 1M times, i.e. i do not have to refresh before i have written 1M times.
that's exactly the opposite of what the section above tells...

it also tells me that data, written to the eeprom once, stay there for > 40 years if i do not rewrite them.


can anyone please tell me what's about with this eeprom specification?
(i need to save calibration data within the eeprom wich is not expected to change for years...)

thanx!
tino

--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

2009\05\05@051652 by Jan-Erik Soderholm

face picon face
The "problem" is if you have some EEPROM cells that are
updated a lot and at the same time some cells that are
never updated. The updates of the first cells will wear
out the second cells and D124 is the limit.

If you always update *all* (used!) cells, all is fine, no
extra refresh needed.

If you do not write to *any* cell (apart from the
first write), the retention is 40 years.

Jan-Erik.



spam_OUTpic.listTakeThisOuTspamgmx.ch wrote:
{Quote hidden}

2009\05\05@090647 by Sean Breheny

face picon face
Hi Jan-Erik,

Here is how I understand what you are saying:

Let's say I write something to address 0 in the EEPROM, and then write
something else to address 1.

Then, I do 100k more writes to address 0. If I read address 1, the
data will still be valid.

If I then do 1M writes to address 0, the data at address 1 may not be
valid anymore.

However, if I now write new data to address 1, it will be valid and
will remain so until I do 1M writes either to address 1 or any other
address in the EEPROM array.

Is it still true, though, that doing more than 1M writes to any given
cell damages that cell permanently?

Also, for the 40 year data retention, I didn't think that was affected
by the number of writes as long as you never exceeded 1M. In other
words, if I write data to addresses 0 and 1, and then do nothing more,
that data will be retained for 40 years. If I start with a fresh PIC
and write data to locations 0 and 1, but then I go and write data to
address 0 500k times and then do nothing further, the data at location
0 and location 1 will remain for 40 years, still. It is only if I
exceed 1M writes to any location - then that location may never work
properly again and in addition, every other location in the EEPROM
array may now have corrupted data unless I read and re-wrote it
recently.

Is this correct?

It seems as if this refresh requirement is new - does this reflect a
change in the underlying EEPROM design which Microchip is using?
Previously I had thought that each EEPROM cell was independent.
Writing 1M times to one cell only affected that cell, not all the
rest.

Thanks,

Sean



On Tue, May 5, 2009 at 5:16 AM, Jan-Erik Soderholm
<.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:
{Quote hidden}

> -

2009\05\05@093435 by Jan-Erik Soderholm

face picon face
Sean Breheny wrote:
> Hi Jan-Erik,
>
> Here is how I understand what you are saying:
>
> Let's say I write something to address 0 in the EEPROM, and then write
> something else to address 1.
>
> Then, I do 100k more writes to address 0. If I read address 1, the
> data will still be valid.
>
> If I then do 1M writes to address 0, the data at address 1 may not be
> valid anymore.

"*May* not be" is the key here. There is no guarantie.
And not only writes to address 0, to any other address (then 1).
It's the *sum* of writes to *any* address (but 1) that "wears out"
the values in address 1.

> However, if I now write new data to address 1, it will be valid and
> will remain so until I do 1M writes either to address 1

Not beacuse of the refresh-problem, that is due to the max-number-
of-writes to any single cell.

> or any other
> address in the EEPROM array.

Yes.

>
> Is it still true, though, that doing more than 1M writes to any given
> cell damages that cell permanently?

Maybe, if that is the actual number, I havn't checked.

> Also, for the 40 year data retention, I didn't think that was affected
> by the number of writes as long as you never exceeded 1M. In other
> words, if I write data to addresses 0 and 1, and then do nothing more,
> that data will be retained for 40 years. If I start with a fresh PIC
> and write data to locations 0 and 1, but then I go and write data to
> address 0 500k times and then do nothing further, the data at location
> 0 and location 1 will remain for 40 years, still.

There is of course no distinct "knee" here. After doing 500K writes
*I* would not expect 40 years retention from address 1 (if not
"refreshed", of course).

> It is only if I
> exceed 1M writes to any location...

Again, note the "typical", "minimal", "maximum" values (if available).

> - then that location may never work
> properly again and in addition,...

Yes. If 1M is the actual value (I have not checked).


> every other location in the EEPROM
> array may now have corrupted data unless I read and re-wrote it
> recently.

That is the "refresh" problem exactly, yes.

> It seems as if this refresh requirement is new - does this reflect a
> change in the underlying EEPROM design which Microchip is using?

New? What deas "new" mean to you ? I have not seen a datasheet that
does *not* talk about "refresh" of the EEPROM area.

{Quote hidden}

>> --

2009\05\05@114709 by Sean Breheny

face picon face
Hi Jan-Erik,

On Tue, May 5, 2009 at 9:34 AM, Jan-Erik Soderholm
<jan-erik.soderholmspamspam_OUTtelia.com> wrote:
>> It seems as if this refresh requirement is new - does this reflect a
>> change in the underlying EEPROM design which Microchip is using?
>
> New? What deas "new" mean to you ? I have not seen a datasheet that
> does *not* talk about "refresh" of the EEPROM area.
>

Thanks for the reply and explanation.

Do you have any information on what the mechanism is by which writes
to one cell can affect the other cells?

When I said "new", I meant new to the 18F series. I don't remember any
of the 16F series datasheets talking about the need to refresh the
EEPROM. They simply stated that the "endurance" was 1M cycles minimum,
10M typical (for the 16F628 for example). I had thought that this was
for each cell independently (hence the reason why people tended to do
wear-leveling when writing data frequently - i.e., if you had a value
which changed frequently, you might write it to any one of several
locations in a round-robin sequence to minimize the wear to each
particular cell).

Sean

2009\05\05@120855 by Jan-Erik Soderholm

face picon face
Sean Breheny wrote:
> Hi Jan-Erik,
>
> On Tue, May 5, 2009 at 9:34 AM, Jan-Erik Soderholm
> <@spam@jan-erik.soderholmKILLspamspamtelia.com> wrote:
>>> It seems as if this refresh requirement is new - does this reflect a
>>> change in the underlying EEPROM design which Microchip is using?
>> New? What deas "new" mean to you ? I have not seen a datasheet that
>> does *not* talk about "refresh" of the EEPROM area.
>>
>
> Thanks for the reply and explanation.
>
> Do you have any information on what the mechanism is by which writes
> to one cell can affect the other cells?

Nop. I just know what one is expected to do... :-)
But I *guess* that it is the higher voltage (?) when
writing that "spills over" to other cells and creates
a (very) small discharge of other cells...

2009\05\05@130724 by Sean Breheny

face picon face
I just found the following:

http://www.piclist.com/techref/mem/eeprom/corruption.htm

with the key point being (this is a quote from the above link):

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.


Sean


On Tue, May 5, 2009 at 12:08 PM, Jan-Erik Soderholm
<KILLspamjan-erik.soderholmKILLspamspamtelia.com> wrote:
{Quote hidden}

> -

2009\05\05@170438 by Bob Axtell

face picon face
This reduction in EEPROM reliability began when the "Nanowatt" series
designs were implemented. I spent weeks working out an algorithm that
truly worked. I finally did.

First, here is what Microchip did: they reduced the size of the EEPROM cell to
such a great extent that the device almost no longer functions. In a
panic, they coughed
up lavish excuses as to why it no longer worked. But many old-timers
simply tested and retested the PIC16Cxxx devices, and sure enough, no
EEPROM failures were found.

While Microchip's schemes might work fine, what I use 99% of the time
is "Best 3 of 5".
The way this works is that instead of writing the EEPROM just once, I
write 5 times, distributed over the array. When I need to read the
byte, I read all 5 bytes and compare
the 5 bytes with each other. If all 5 bytes are identical, nothing
happens- the value is simply used. But if a byte is not the same, the
algorithm locates at least 3 that ARE the same, and uses that as the
value, then write all 5 bytes again (to 'refresh them..?'). I have
never had to
fiddle with that routine since.

I have found that writing into program memory is much more reliable,
and I use it as much as possible.

--Bob A

On Tue, May 5, 2009 at 10:07 AM, Sean Breheny <spamBeGoneshb7spamBeGonespamcornell.edu> wrote:
{Quote hidden}

>> -

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