Searching \ for '[PIC] EEPROM: array refresh concept (18F4680 etc)' 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: 'EEPROM: array refresh concept (18F4680 etc)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] EEPROM: array refresh concept (18F4680 etc)'
2007\12\13@074346 by Matthew Rhys-Roberts

flavicon
face
Will someone correct me if I'm wrong about this?

As far as I can tell, writing (i.e. erase-writing) to any PIC EEPROM
address will disrupt the stored charge in neighboring memory cells.
Eventually, if written enough times, EEPROM data corruption may result.
Microchip recommend using an EEPROM refresh routine periodically, in
cases where erase-write cycles are likely to approach 1- to 10-million
times ("specification D124").

I'm only asking so I can make a sensible choice between EEPROM and Flash
program memory, for storing some infrequently changed non-volatile
constants.

Thanks

Matt

2007\12\13@083120 by Xiaofan Chen

face picon face
On Dec 13, 2007 8:38 PM, Matthew Rhys-Roberts <spam_OUTmattTakeThisOuTspamnu-ins.com> wrote:
> Will someone correct me if I'm wrong about this?
>
> As far as I can tell, writing (i.e. erase-writing) to any PIC EEPROM
> address will disrupt the stored charge in neighboring memory cells.
> Eventually, if written enough times, EEPROM data corruption may result.
> Microchip recommend using an EEPROM refresh routine periodically, in
> cases where erase-write cycles are likely to approach 1- to 10-million
> times ("specification D124").

Which PIC are you using? Have you checked the errata?

> I'm only asking so I can make a sensible choice between EEPROM and Flash
> program memory, for storing some infrequently changed non-volatile
> constants.

I can not relate this paragraph with the previous paragraph.
Since it is infrequent, you can use either EEPROM or Flash
but I think EEPROM is easier if your PIC has the EEPROM.

Anyway, you need to tell us which PIC you are going to use first.

Xiaofan

2007\12\13@083733 by Jan-Erik Soderholm

face picon face
Matthew Rhys-Roberts wrote:
> Will someone correct me if I'm wrong about this?
>
> As far as I can tell, writing (i.e. erase-writing) to any PIC EEPROM
> address will disrupt the stored charge in neighboring memory cells.
> Eventually, if written enough times, EEPROM data corruption may result.
> Microchip recommend using an EEPROM refresh routine periodically, in
> cases where erase-write cycles are likely to approach 1- to 10-million
> times ("specification D124").
>
> I'm only asking so I can make a sensible choice between EEPROM and Flash
> program memory, for storing some infrequently changed non-volatile
> constants.

Correct.
Note that with EEPROM you can re-write a single
cell, with flash you have to erase and rewrite
a block of cells (32 or 64 or whatever).

Jan-Erik.



>
> Thanks
>
> Matt

2007\12\13@083926 by Xiaofan Chen

face picon face
On Dec 13, 2007 9:30 PM, Xiaofan Chen <.....xiaofancKILLspamspam@spam@gmail.com> wrote:
{Quote hidden}

Oops, I did not notice the subject header (Gmail hides the
header by default). So you are talking about 18F4680.

I do not notice any mentioning of EEPROM issues
in the errata. So I will use the EEPROM and test it to see
if there is any problem or not.

There are 4 errata documents.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010305

Xiaofan

2007\12\13@085603 by Tamas Rudnai

face picon face
BTW: What does it mean "infrequent"? You can overwrite flash about 1k times,
but it's not guaranteed. You can store calibration data for example that you
made only once or twice and you can make the FW update couple of times but I
would not rely on it.

Anyway, if you need permanent storage other than the internal eeprom why do
not you use some external ones with spi or i2c?

Tamas


On Dec 13, 2007 1:30 PM, Xiaofan Chen <.....xiaofancKILLspamspam.....gmail.com> wrote:

{Quote hidden}

> -

2007\12\13@090918 by Bob Axtell

face picon face
Matthew Rhys-Roberts wrote:
> Will someone correct me if I'm wrong about this?
>
> As far as I can tell, writing (i.e. erase-writing) to any PIC EEPROM
> address will disrupt the stored charge in neighboring memory cells.
> Eventually, if written enough times, EEPROM data corruption may result.
> Microchip recommend using an EEPROM refresh routine periodically, in
> cases where erase-write cycles are likely to approach 1- to 10-million
> times ("specification D124").
>
> I'm only asking so I can make a sensible choice between EEPROM and Flash
> program memory, for storing some infrequently changed non-volatile
> constants.
>
> Thanks
>
> Matt
>  
During a lengthy test three years ago, I noticed those failures, too.

Microchip's approach of overwriting the entire array seems a bit like
owning an elephant to kill
roaches in your parlor by stepping on them; its clumsy.

A sleeker approach is to simply write the variable 3 times, rather than
just once. When you read it back, read
all three copies; if one doesn't match, then rewrite all three (using
the two that match). In 3 years of use, I've not
seen another failure. This concept is "best 2 of 3". I used "best 3 of
5" in a military application.

BTW, in the Nanowatt series of PICs, it is strange to me that the
program memory  is more reliable than the
EEPROM memory, but it _IS_. I have stored variables in the program
memory of the  PIC16F87 and '88,
never had a single failure, and to do so took less code space than "best
2 of 3" EEPROM method.

--Bob A

2007\12\13@091411 by Brendan Gillatt

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Rhys-Roberts wrote:
> I'm only asking so I can make a sensible choice between EEPROM and Flash
> program memory, for storing some infrequently changed non-volatile
> constants.

Unless you're running it for 50 years you probably won't need to update
the values if written infrequently. The datasheet only specifies doing a
refresh if data is written to EEPROM very frequently.


- --
Brendan Gillatt
brendan {at} brendangillatt {dot} co {dot} uk
http://www.brendangillatt.co.uk
PGP Key: pgp.mit.edu:11371/pks/lookup?op=get&search=0xBACD7433
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFHYT4ukA9dCbrNdDMRAtD8AJ4pxAYFPRwy4iuzbqORHdi8e0OnZgCgoWiW
A6j/TXS9MGzaotohZKJPd48=
=3CQa
-----END PGP SIGNATURE-----

2007\12\13@101831 by Timothy Weber

face picon face
Bob Axtell wrote:
> A sleeker approach is to simply write the variable 3 times, rather than
> just once. When you read it back, read
> all three copies; if one doesn't match, then rewrite all three (using
> the two that match). In 3 years of use, I've not
> seen another failure. This concept is "best 2 of 3". I used "best 3 of
> 5" in a military application.

But this doesn't address the same set of issues as the "refresh
everything" approach, does it?  E.g., if one very rarely-written
variable has two or more of its duplicates stored next to those of
frequently-written variables, it could get compromised before you read
it back again, no?

It seems like your approach is superior specifically when most variables
are re-written with pretty much the same frequency - or when you can
segregate them into blocks of quick-changing and slow-changing
variables, and store them in regions of EEPROM that aren't adjacent
(however you can determine that).
--
Timothy J. Weber
http://timothyweber.org

2007\12\13@105758 by M. Adam Davis

face picon face
On 12/13/07, Timothy Weber <twspamspam_OUTtimothyweber.org> wrote:
> But this doesn't address the same set of issues as the "refresh
> everything" approach, does it?  E.g., if one very rarely-written
> variable has two or more of its duplicates stored next to those of
> frequently-written variables, it could get compromised before you read
> it back again, no?

In the automotive industry variable copies are required to be
separated in memory (never adjacent), they all require CRC (on a per
variable basis), and often a sequence number as well so if an update
goes awry then the latest copy is used.  Of course, they also
generally require a wear levelling scheme, so you never write any one
cell more than other cells, and variables are never located in any
particular spot.

These measures use up 6x as much EEPROM space (double redundancy, CRC,
sequence) but resolve all of the mentioned issues.

At the end of the day it's an issue of how much reliability your
application requires.  When someone is asking about the adjacent cell
damage associated with EEPROMs, I would assume they need a very high
level of confidence, and recommend at minimum error checking (ideally
error correction of one bit, detection of two) and a reasonable wear
levelling scheme.

An advantage of a good wear levelling scheme is that if the current
copies of the variable are bad, one can go back to the previous copy
if that is appropriate.

Infrequently changing variables are a burden to a good wear levelling
scheme, though, so one might consider partitioning variable usage into
two or more levels based on frequency of change.

-Adam

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - -
Moving in southeast Michigan? Buy my house: http://ubasics.com/house/

Interested in electronics? Check out the projects at http://ubasics.com

Building your own house? Check out http://ubasics.com/home/

2007\12\13@120157 by Jan-Erik Soderholm

face picon face
Timothy Weber wrote:

> E.g., if one very rarely-written
> variable has two or more of its duplicates stored
> next to those of > frequently-written variables,...

"next to" ?

I've not seen anything in the datasheets saying that
the refresh requirements depends on the actual
placement on the data in the actual EEPROM.

Jan-Erik.

2007\12\13@122856 by Bob Axtell

face picon face
Jan-Erik Soderholm wrote:
> Timothy Weber wrote:
>
>  
>> E.g., if one very rarely-written
>> variable has two or more of its duplicates stored
>>    
>  > next to those of > frequently-written variables,...
>
> "next to" ?
>
> I've not seen anything in the datasheets saying that
> the refresh requirements depends on the actual
> placement on the data in the actual EEPROM.
>
> Jan-Erik.
>  
I don't think that MC ever went that far, but some literature covers
adjacent-
cell issues, which occurred in other memory types as well.

Agreed, Microchip didn't seem to want to cover the issue in much detail.

--Bob

2007\12\13@132252 by Tamas Rudnai

face picon face
So if we write an app that put some "sandwiches" like 0x55-0xNN-0x55 ...
0xAA-0xNN-0xAA  and then continuously overwrite the 0xNN and see if those
sandwiches damaged? Put a counter to LED or LCD and report errors to RS232
when something is wrong...

If we have 2 of these sandwiches and wait 5ms for each write then it takes
around 3 hrs to see if something is wrong (1mill writes). We would need to
test it with 3V as well I suppose? What did I miss out, temperature?
Moisture? Clock settings? Electrical noises? Too many chips to damage :-)

Tamas



On Dec 13, 2007 5:28 PM, Bob Axtell <@spam@engineerKILLspamspamcotse.net> wrote:

{Quote hidden}

> -

2007\12\13@140335 by Richard Prosser

picon face
On 14/12/2007, Bob Axtell <KILLspamengineerKILLspamspamcotse.net> wrote:
{Quote hidden}

Bob,
Why "best 3 of 5"? I would have thought "Best 3 or 4 of 5" would have been a
better schene?

RP

2007\12\13@142936 by Bob Axtell

face picon face
Richard Prosser wrote:
{Quote hidden}

Most of the time it is "5 of 5". But to keep the algorithm as small as
possible, it takes the first 3 that match
and uses it, but it examines all 5; if one doesn't match it overwrites
all 5. I guess I was vague...sorry.

--Bob

2007\12\13@145639 by Gerhard Fiedler

picon face
Brendan Gillatt wrote:

> Matthew Rhys-Roberts wrote:
>> I'm only asking so I can make a sensible choice between EEPROM and Flash
>> program memory, for storing some infrequently changed non-volatile
>> constants.
>
> Unless you're running it for 50 years you probably won't need to update
> the values if written infrequently. The datasheet only specifies doing a
> refresh if data is written to EEPROM very frequently.

The problem you may be facing is that the endurance of data cells that are
written to infrequently is affected by the writes to other data cells if
those happen frequently enough.

Gerhard

2007\12\14@042348 by Matthew Rhys-Roberts

flavicon
face
Thanks everybody for all the responses up to this point!

I'm only storing factory settings, not any sort of 'live' data. The
settings are unlikely to change more than a few times in the unit's
lifetime, hopefully.

This discussion has been useful for the case of e.g. signal
recording/processing applications in the future.

Best regards,
Matt


Matthew Rhys-Roberts wrote:
> Will someone correct me if I'm wrong about this?
>  

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