|
|
View previous topic :: View next topic |
Author |
Message |
pfournier
Joined: 30 Sep 2003 Posts: 89
|
Write then Read of data eeprom is no proof of saved data |
Posted: Wed May 17, 2006 3:17 pm |
|
|
18f8622 PCWH 3.249
I mistakenly wrote enough times to a section of my data eeprom to wear out 2 bytes.
As a side effect of this I have discovered that if you write to the eeprom then read, the data looks just fine!!!! You only discover there is a problem after you cycle power or reset.
Does anyone know if there a way around this, or is it just the way the silicon is made? _________________ -Pete |
|
|
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
Re: Write then Read of data eeprom is no proof of saved data |
Posted: Wed May 17, 2006 3:44 pm |
|
|
pfournier wrote: | I mistakenly wrote enough times to a section of my data eeprom to wear out 2 bytes.
Does anyone know if there a way around this, or is it just the way the silicon is made? |
It's the way the silicon is made. Those 2 bytes are gone. Obviously, you can do two things:
- Choose another pair of bytes that haven't been worn out.
- Replace the PIC. |
|
|
Guest
|
|
Posted: Thu May 18, 2006 6:23 am |
|
|
You misunderstood my note, and after rereading it I can see how. I don't want the bytes back, I want to know how I can be assured that the data EEPROM really has saved my data without power cylcling or resetting the processor. |
|
|
Ttelmah Guest
|
|
Posted: Thu May 18, 2006 6:45 am |
|
|
The problem is that certain damage modes, can result in an EEPROM, which writes OK, and holds it's data till the power is removed. Then the data is lost, over days, hours, or even minutes. Unfortunately, the write, followed by read test, will see the data as OK, but then latter the contents degrade...
Dealing with this type of failure is hard. One solution, is to add a checksum elsewhere. On a particular application where high reliability was needed, I switched to using a 24:16 Shannon code, writing three bytes for every two that were needed, with a high probability of detecting failure, or recovering the data. Generally, if I remember correctly, failures result in the bits becoming 'set', so something like writing a second bitwise invert of the byte to the next cell, and assuming if there is a difference, when reading the two bytes, and inverting the second, that the one which has the low value stored is the 'correct' result, should work.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|