Spurious write or corrupting EEPROM ???

[Mr.Anderson]

Hi,
I have a project where the PIC (16f628, 16f628a and other compatible) are suffering the same problem: they are modifying some of the eeprom contents without any aparent reason.
The PIC is connected to an external device and communicates with this device digitally, using bit bang, TTL levels, one port in and one port out. The software reads data from the eeprom at power up and later it may rewrite the eeprom to update data.
The problem is that most times, soon or later, the same 5 addresses of the eeprom become corrupt. There are about 10 addresses that are read at power up, but always the same first 5 addresses that are read will have their contents corrupt. The interesting thing is that these 5 addresses will never change their contents. They are read only. Other address on the eeprom are updated once every two months or more...
I've already implemented in software a power up delay of 2 seconds because I suspected the power could be oscillating at power up while the PIC could be reading the eeprom. After changing, the problem happens less often than before, but it still happens. I've also simulated the code in MP-LAB and in Isis and this issue never happens in the simulations.

Could anybody give any advice on this?

Thanks in advance.

 

[hjames]

Do you have "brownout" detection enabled?

 

[Mr.Anderson]

Yes. Actually I enabled brown out detection to try to solve this problem.

 

[Nigel Goodwin]

The convoluted measures required for actually writing to the EEPROM are to avoid problems like this - I would suggest it's 'probably' a software bug, and the EEPROM write routine is getting called when it shouldn't be?.

It's also a MAJOR problem in modern TV's, EEPROM corruption has been a big problem since sets started using them.

 

[hjames]

If you've checked the contents of the EEPROM to see if they make any sense and you are *absolutely* sure that no combinations of interrupts, inputs, register states can cause this problem... the only thing is error recovery.Keep backup copies of the data and checksums on each of them. If a checksum fails, then switch to another backup copy. When writing data, update the checksum accordingly.

This obviously is pretty demanding on the EEPROM, especially the poor cell that has to hold the checksum variable.

 

[eblc1388]

I would suggest to relocate the 5 eeprom addresses where the content is unlikely to be changed to other parts of the eeprom page or store them in different order wrt the changing content and see if the situation improved.

This is to confirm that they are not altered un-intentionally while you were trying to update those addresses that have the content changed.

If reading from eeprom changes data content, then I would expect most of us would see a lot more postings about this behaviour in this forum.