On Thursday 08 September 2005 07:47 am, Bob Axtell scribbled:
> This has come up before on the list. I did a consulting job on this and
> here is what I
> decided:
>
> 1. This problem is unique to the newer PIC's, and was not noticed with
> PIC16C??? devices.
> The problem exists on other EEPROMs built from other vendors, including
> ATMEL and
> others, as well.

Since you reference "16C...", I assume newer includes the flash devices such 
as the 16F628 in this case?


> 2. It seems that there is now a requirement to periodically refresh the
> EEPROM. Microchip
> recommends it  but the reason was never clear. Their method takes too
> much code space
> to implement.

Ooohhh... that sucks.  I was really really trying to optimize the "system" so 
that I don't overrun the min write cycles spec, and have just barely been 
able to do so.  Refreshes would put me over that amount.  This also brings up 
haunting memories of "CAS before RAS" dram refreshing.  <Shudder>.

Do you know the Microchip document that talks about this?  I'm searching their 
site now but not coming up with anything relevant.  I'd also like to know is 
how periodic is periodic.  


> 3. The best way to solve this seems to be  to write the code so that
> data was written in triplicate,
> and when read back, use the "best two of three" method to decide what
> data to use. When
> writing, write all three in ONE PASS, then read them back to make sure
> all three are written.

In my case though, it appeared that *all* data was corrupted, which I'm 
guessing would not be helped by triplicating.  BTW, by "one pass" you mean to 
do nothing else between writes of a single dataset?  I have too much else 
going on, so I write and set a flag that one byte is written, then go do 
other things.  The main code loop sees that other bytes are waiting to be 
written and keeps checking the flags.  When a write is complete, it sets up 
the next write, etc.


> This solved the problem for my client and hasn't arisen since.
>
> --Bob


I may have to re-engineer the "system", but I'm guessing my solution also lies 
with something like this.  I'd really really really like to avoid using an 
external EEPROM for space reasons, and I'm sure I don't have enough free 
pins.  If I did, I could've even used both the internal and an external 
EEPROM and cross-check -- sort of like an EEPROM RAID system! :-)

Cheers,
-Neil.



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