This should give you an idea of how far I am behind on email. The spec is 1M min, 10M typical. Depending on your use, a refresh may never be required. If however you are writing a byte to EEPROM every second, you may start to lose unrefreshed data in 11.57 days. Chad --- In piclist@picl..., "Rick" <olduffer@b...> wrote: > --- Peter van Hoof <pvhoof@y...> wrote: > > The refresh is needed because when writing to one > > eeprom cell part of the charge on neighboring cells > > that is needed to retain its contents is lost. > > > > If a cell is almost never written to but the cell next > > to it is often at a certain point it will lose it's > > contents... unless you refresh it's data once in a > > while (read the contents and write them back) > > Thanks, that makes sense. Would it have killed them to > just say that? So now I'm thinking maybe I run refresh > as part of powerup/reset/initialization. > > --- Eirik Karlsen <eikarlse@o...> wrote: > > You can find the D-spec's in the datasheet, "DC > > Characteristics"... > > in the 18F242 datasheet anyway. > > Thanks, I'll have a look at that also.

--- Peter van Hoof <pvhoof@y...> wrote: > The refresh is needed because when writing to one > eeprom cell part of the charge on neighboring cells > that is needed to retain its contents is lost. > > If a cell is almost never written to but the cell next > to it is often at a certain point it will lose it's > contents... unless you refresh it's data once in a > while (read the contents and write them back) Thanks, that makes sense. Would it have killed them to just say that? So now I'm thinking maybe I run refresh as part of powerup/reset/initialization. --- Eirik Karlsen <eikarlse@o...> wrote: > You can find the D-spec's in the datasheet, "DC > Characteristics"... > in the 18F242 datasheet anyway. Thanks, I'll have a look at that also.

This is what i was thinking until someone made me aware of the nature of the problem. The refresh is needed because when writing to one eeprom cell part of the charge on neighboring cells that is needed to retain its contents is lost. If a cell is almost never written to but the cell next to it is often at a certain point it will lose it's contents... unless you refresh it's data once in a while (read the contents and write them back) There is no exact spec given for when this actually has to be done but microchip suggests putting values that hardly ever changes in program memory and data regularly rewritten in data eeprom. Kind regards Peter van Hoof --- Eirik Karlsen <eikarlse@eika...> wrote: > Rick, > Yes it is confusing and I suggest you just ignore > it. > D123 and D134 states a data retention time of > 40 years for both FLASH and EEPROM so basically > you don't need to worry about it. > > You can find the D-spec's in the datasheet, "DC > Characteristics"... > in the 18F242 datasheet anyway. > > Rick wrote: > > > > > I'm thinking about using the Data EEPROM in an > 18F8620, and can't > > figure out what the datasheet is trying to say. I > hope someone > > can clarify. > > > > Section 7.8 says, in part "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 ... should be stored in > Flash program > > memory." > > > > But here's the catch: there is no specification > D124 anywhere to be > > found in the data sheet, therefore no frame of > reference for fuzzy > > relative terms "frequently" and "infrequently". > > > > Then, perversely, they go on to say "Note: If data > EEPROM is only > > used to store constants and/or data that changes > rarely, an array > > refresh is likely not required. See specification > D124." > > > > And again, since there is no "specification D124", > there is no frame > > of reference for the relative term "rarely". Also > notice fuzzy words > > "likely not required". > > > > And then they proceed to give sample code for a > refresh routine that > > is obviously going to consume a significant amount > of processing time, > > > > so not something I would want in my main loop, but > they give no > > guidelines. > > > > Near as I can gather, it must be fine if you > change it constantly or > > never, but there is some window between > milliseconds and centuries > > where problems can occur, the datasheet author did > not understand the > > situation, and the engineers didn't deem it worthy > to supply any > > usable information. > > > > Can anyone shed light on this? > > > > -- > ******************************************* > VISIT MY HOME PAGE: > <http://home.online.no/~eikarlse/index.htm> > LAST UPDATED: 23/08/2003 > ******************************************* > Regards > Eirik Karlsen

Rick,
Yes it is confusing and I suggest you just ignore it.
D123 and D134 states a data retention time of
40 years for both FLASH and EEPROM so basically
you don't need to worry about it.

You can find the D-spec's in the datasheet, "DC Characteristics"...
in the 18F242 datasheet anyway.

Rick wrote:

I'm thinking about using the Data EEPROM in an 18F8620, and can't
figure out what the datasheet is trying to say. I hope someone
can clarify.
Section 7.8 says, in part "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 ... should be stored in Flash program
memory."
But here's the catch: there is no specification D124 anywhere to be
found in the data sheet, therefore no frame of reference for fuzzy
relative terms "frequently" and "infrequently".
Then, perversely, they go on to say "Note: If data EEPROM is only
used to store constants and/or data that changes rarely, an array
refresh is likely not required. See specification D124."
And again, since there is no "specification D124", there is no frame
of reference for the relative term "rarely". Also notice fuzzy words
"likely not required".
And then they proceed to give sample code for a refresh routine that
is obviously going to consume a significant amount of processing time,
so not something I would want in my main loop, but they give no
guidelines.
Near as I can gather, it must be fine if you change it constantly or
never, but there is some window between milliseconds and centuries
where problems can occur, the datasheet author did not understand the
situation, and the engineers didn't deem it worthy to supply any
usable information.
Can anyone shed light on this?

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen

I'm thinking about using the Data EEPROM in an 18F8620, and can't figure out what the datasheet is trying to say. I hope someone can clarify. Section 7.8 says, in part "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 ... should be stored in Flash program memory." But here's the catch: there is no specification D124 anywhere to be found in the data sheet, therefore no frame of reference for fuzzy relative terms "frequently" and "infrequently". Then, perversely, they go on to say "Note: If data EEPROM is only used to store constants and/or data that changes rarely, an array refresh is likely not required. See specification D124." And again, since there is no "specification D124", there is no frame of reference for the relative term "rarely". Also notice fuzzy words "likely not required". And then they proceed to give sample code for a refresh routine that is obviously going to consume a significant amount of processing time, so not something I would want in my main loop, but they give no guidelines. Near as I can gather, it must be fine if you change it constantly or never, but there is some window between milliseconds and centuries where problems can occur, the datasheet author did not understand the situation, and the engineers didn't deem it worthy to supply any usable information. Can anyone shed light on this?