Programming PIC causes Device ID to become unrecognisable

Hi All,
 
I'm working with the PIC16F88, and have used it in several other projects in the past. I can therefore confirm that there is no problem with my hardware configuration as I don't experience any problems when I try to program my other projects.
 
My most recent code commit causes the PIC to gain an unrecognisable Device ID when programmed. 

Steps:
Press Make and Program Device Main Project
Device ID recognised, Device Erased, Programming, program/verify complete, etc
Press Make and Program Device Main Project a second time (Even without removing the PIC from the burner)
"Target Device ID (0x0) is an Invalid Device ID. Please check your connections to the Target Device."
If I press "OK" to continue, I see (regular output followed by):
Address: 0 Expected Value: 2a1b Received Value: 0
Failed to program device
 
If I try to reprogram one of these 'killed' PIC with another 'known good' project, then I experience the same problems.
 
Strangely, my code seems to burn onto the device correctly, as these 'killed' PICs continue to function in my application.
 
I'm programming the PICs with assembly and a genuine PICkit 3, am using ~800 of my 4K of program memory, am using all of my 256 EEPROM bytes. HVP is being used and the PIC in the programming jig is powered from a (tested good) external 5V source. Configuration words are 2D58 / 3FFC.
 
I'm kind of flummoxed by this, and to date I've rendered 6 PIC16F88s non-functional by trying to write to them after commenting some sections of code out to try to narrow down the problem. I only have a few of these devices left now and I don't want to ruin more (and run out). I also don't want to revert the commit as I need the functionality it implements (and I've seen it working, because, as stated previously, the chip still functions, I just can't read it/burn it anymore). 

Does anyone have any idea what I'm doing wrong or what is going wrong here?
 
Jet Holt

Some of the older pics had an issue with programming if the MCLR was disabled (as you have) and PORTB was set to output mode too quickly out of reset, a delay was needed before changing the direction of the port pins to allow the entry into programming mode correctly (I think I have this right, been a while).

@jack@kksound
 
Yep, that seems to be the problem. I added a 100ms delay before my code and now I don't see a problem.
 
Is there any way to recover my chips that have the old code?
 
Regards,
Jet Holt. 

I understand there is a setting in the pickit3 that may help, something about "Vpp first" program mode or like that.
 EDIT: I may have that setting name wrong, I can't look at it right now.

@ric,
I'm using MPLABX v5.05 with a PICkit 3 on Linux.
I don't see a "Vpp before Vdd" option in my project properties. Does it require using the PICkit 3 to power the target?

You may find that just enabling the PK3 to power the PIC is all you need to be able to reprogram the chips.
 

Hi Jet,
 
I experimented the same problem, more than once, when sometimes I made wrong GND reference connection.
In example I was debugging an application, supplying the target board with an isolated transformer, and than I conncted the scope probe.
 
Probably due to a pretty high current flowing on the EARTH connection, the PIC broke and I was no more able to program it.
So, my advise,  if you're debugging the board, avoid to connect it to any other electrical device, if not fully isolated.
 
Rgds, Luca   
 
 

I just upgraded to 5.30, but I still don't see 'VPP before VDD' in my project properties.
 
 

Remove power from your PIC.
 
Build a circuit which powers your PIC at 5V when MCLR goes to 13V - the simplest way is an 8 V zener between MCLR and VDD, or a chain of diodes.
 
Configure PICkit3 not to provide power, disconnect VDD pin of the PICkit3 connecter from your PIC and connect it to 5V.
 
Then erase.

You have brown-out reset enabled. Is it possible to try erasing with a VDD below the brown-out threshold, so the program doesn't start? It looks as if the threshold is 4V.
Even if it corrupts you should'd then be able to re-program at 5V.