Odd EEPROM behaviour with PICKit3
Posted: Tue Aug 19, 2014 4:20 pm
This is a very odd one, I hope someone else has seen this and found a solution!
Basically, if I use the Read or Blank Check functions in the PICKit3 programmer app to force a device reset it seems to corrupt some EEPROM values. Cycling the power works without problem.
I can't for the life of me work out what is going on! I sometimes use this as an easy way to reset the processor when I'd debugging - cycling power isn't ideal on my current system as I'm also using an RN42 Bluetooth module which I keep connected to a PC terminal. If I just reset the PIC then this stays connected, if I cycle the power I have to reconnect it.
So far it seems to be resetting locations $24 and $29 to $FF. I don't know about any others, I need to try and work out how to read the device to check the EEPROM contents without using the Read function as this is what causes the corruption!
While I would hope the unit would never see this type of reset in service I'd like to get to the bottom of the problem so I can take steps to prevent it happening in service if necessary.
Basically, if I use the Read or Blank Check functions in the PICKit3 programmer app to force a device reset it seems to corrupt some EEPROM values. Cycling the power works without problem.
I can't for the life of me work out what is going on! I sometimes use this as an easy way to reset the processor when I'd debugging - cycling power isn't ideal on my current system as I'm also using an RN42 Bluetooth module which I keep connected to a PC terminal. If I just reset the PIC then this stays connected, if I cycle the power I have to reconnect it.
So far it seems to be resetting locations $24 and $29 to $FF. I don't know about any others, I need to try and work out how to read the device to check the EEPROM contents without using the Read function as this is what causes the corruption!
While I would hope the unit would never see this type of reset in service I'd like to get to the bottom of the problem so I can take steps to prevent it happening in service if necessary.