Spurious write or corrupting EEPROM ??? - Electronic Circuits Projects Diagrams Free

Mr.Anderson · 18th August 2006, 05:41 PM

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 · 18th August 2006, 05:49 PM

Do you have "brownout" detection enabled?

Mr.Anderson · 18th August 2006, 07:28 PM

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

**Nigel Goodwin** · 18th August 2006, 07:40 PM

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 · 18th August 2006, 10:10 PM

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 · 19th August 2006, 01:33 AM

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.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

18th August 2006, 05:41 PM	(permalink)
Mr.Anderson	Spurious write or corrupting EEPROM ??? 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.

18th August 2006, 05:49 PM	(permalink)
hjames	Do you have "brownout" detection enabled?

18th August 2006, 07:28 PM	(permalink)
Mr.Anderson	Yes. Actually I enabled brown out detection to try to solve this problem.

18th August 2006, 07:40 PM	(permalink)
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. __________________ PIC programmer software, and PIC Tutorials at: http://www.winpicprog.co.uk

18th August 2006, 10:10 PM	(permalink)
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.

19th August 2006, 01:33 AM	(permalink)
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. __________________ L.Chung