Sean,

I agree that we need clarity.

If you notice, you don't need to do any "refreshing" for serial EEPROMS-
even huge ones (1M bits), so apparently the nanowatt EEPROM is a
different, (i.e. less robust), animal.

Somebody from Microchip needs to step up to the plate and CLEARLY explain
what is going on. These failures began when the nanowatt series came out,
and was not a problem before that.

--Bob


> On Thu, Oct 29, 2009 at 1:55 PM, Dwayne Reid <dwayner@planet.eon.net>
> wrote:
>>
>> So far as I know, reading the eeprom does NOT cause the
>> problems, =A0Instead, the problem is caused by many writes to one part
>> of the eeprom array. =A0Those bytes that are frequently written are NOT
>> the problem. =A0What does get affected is eeprom addresses that DON'T
>> get written.
>>
>
> Dwayne,
>
> This seems to be in dispute. In the recent discussion on this (about 1
> month ago), several people claimed that reads DO degrade the EEPROM
> cell contents in these certain affected PICs. This is not mentioned in
> the datasheets but people seem to claim that the information in the
> datasheets is at best incomplete. I would be very happy to hear
> additional information about this since we have some products out in
> the field which would be severely affected by this. They use nanowatt
> series parts,  continually read the EEPROM, do not store redundant
> values, and write much more frequently to some parts of the array than
> to others. We designed them to be compatible with products originally
> made by another manufacturer so we do not have total flexibility in
> the way the EEPROM is used (i.e., too much of it is used to make
> duplicate copies of each value).
>
> Sean
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist