| View previous topic :: View next topic |
| Author |
Message |
pfournier
Joined: 30 Sep 2003
Posts: 89
|
| Data EEPROM won't survive a software reset |
 Posted: Thu May 04, 2006 2:04 pm |
 |
|
18f8622, pcwh 3.249
I have a situation where at one particular pair of data EEPROM addresses a write followed by a read works fine.
At one time cycling power was fine as well. I suddenly noticed it wasn't correct anymore. As an experiment I set it up to do a software reset ( reset_cpu() ) and noticed that the EEPROM did not even survive that.
I am assuming that by sheer bad luck that these 2 sequential addresses went bad. By using the next pair of available addresses everything seems to work properly.
I just find it odd that 2 adjacent addresses into which I put a 16 bit value should go bad. Am I being paranoid?
_________________
-Pete |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu May 04, 2006 2:24 pm |
|
|
Can you post a small test program that demonstrates the problem ?
If so, we can probably find the problem. The program should be
very short, but complete, and should be able to be pasted into MPLAB
and compiled with no errors. |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
| Re: Data EEPROM won't survive a software reset |
| Posted: Thu May 04, 2006 3:25 pm |
|
|
| pfournier wrote: | | I am assuming that by sheer bad luck that these 2 sequential addresses went bad. By using the next pair of available addresses everything seems to work properly. |
Have you used your current chip for a long time? How many writes have you done to your 2 bad bytes? Each EEPROM byte can withstand only a limited number of writes on the order of 10-100 thousand. If you have been writing a lot to the same location of the EEPROM you could have burned a hole in it. |
|
|
pfournier
Joined: 30 Sep 2003
Posts: 89
|
|
| Posted: Thu May 04, 2006 4:00 pm |
|
|
I will post a simplified program soon. The Data EEPROM is supposed to be good for 1,000,000 erase/write cycles (according to the data sheet).
I'm sure I'm not there yet.
_________________
-Pete |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu May 04, 2006 6:46 pm |
|
|
| It wouldn't take long to kill it with a simple code goof where you write to the eeprom in a loop. |
|
|
sjbaxter
Joined: 26 Jan 2006
Posts: 141
Location: Cheshire, UK
|
|
| Posted: Fri May 05, 2006 2:27 am |
|
|
Sounds like a 'burnt' EEPROM to me.
One thing to always implement with EEPROMs, especially when storing configuration info/data is to do a read first, compare this with the new value and only if the value has changed, do the write back to the EEPROM. or even create your own wrapper function to do this, i.e
| Code: | void MyWrite_EEPROM(int16 addr, int8 value)
{
int8 current;
// write to internal EEPROM
current = read_EEPROM(addr);
if (current != value)
{
write_EEPROM(addr, value);
}
}
|
... that way you only do a write if you have to !
_________________
Regards,
Simon. |
|
|
Ttelmah
Guest
|
|
| Posted: Fri May 05, 2006 5:25 am |
|
|
| pfournier wrote: | I will post a simplified program soon. The Data EEPROM is supposed to be good for 1,000,000 erase/write cycles (according to the data sheet).
I'm sure I'm not there yet. |
First of all, this figure, is 'for guidance only'. Not tested, or certified in any way... The only 'warranted' figure, is the _minimum_ life (100K cycles), and even this has qute a few caveats. There were several batches of older chips, that showed a much higher than specified failure rate. the 'life', also assumes a very stable power supply (the EEPROM life will noticeably degrade in some systems, if the rail varies during the write cycle...).
Now with the '100K' figure, it is suprising how quickly this can be used, if you are not careful in using the feature. For instance, an accidental loop that writes repeatedly, can use the life up in a very short time, but (worse), perfectly 'logical' things, like perhaps 'logging' a reading every second, will use the life up, in just over a day!. hence in such situations,it is 'wise' to consider alternatives, like only writing the data during a power down, using FRAM to hold fast changing values, or only actually 'logging' the data at a much longer interval.
Your symptoms, are those of a EEPROM cell that has aged.
Best Wishes |
|
|
pfournier
Joined: 30 Sep 2003
Posts: 89
|
|
| Posted: Fri May 05, 2006 7:42 am |
|
|
I had a sudden realization. I DID have the write to this address in my main at one time. I got rid of it because I couldn't afford the interrupt loss it caused. In all that time I was writing through every pass of my Main loop. Assuming the loop ran no slower than 100mS, (I'm sure it ran much faster) that's 27 hrs for the 1e6 writes, I probably blew through this baby in one week and didn't even notice! What a DUH!!! Glad it happened here and not in the field.
Thank's for the help guys. I've got to think about this some more to avoid future burnout and find someone to administer a dope slap.
_________________
-Pete |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
| avoiding the EEPROM burnout |
| Posted: Wed May 17, 2006 3:53 pm |
|
|
| pfournier wrote: | | I've got to think about this some more to avoid future burnout. |
There is a couple of ways of :
- Reduce the frequency of writing to the EEPROM.
- Read the EEPROM first and write only if the value had changed (as have been mentioned above).
- If the above techniques can't be applied, you could allocate some reserve location(s) in the EEPROM and keep track of the number of writes. After 1e6 writes switch to a different EEPROM location. Solid state hard drives eploy this technique. |
|
|
Guest
|
|
| Posted: Thu May 18, 2006 6:36 am |
|
|
Actually what I ended up doing was rotating through "blocks" of EEPROM everytime I power up. I also added a "lockout byte" to the block that only ever gets written when I discover corrupted data in the block, so I never use that one again. I employ a checksum that I check on powerup to detect corruption, and in a low write frequency area I keep stuff that doesn't change often.
I almost went with the "write for 1e6 times then move on" but I decided that 1e6 was the upper limit, 1e5 was the spec. And I really didn't want to run to the point of risking my data if I could help it. By spreading out deliberatly I felt I had better control. By the time this baby goes dead, I'll be dead. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
