after programming PICs for years, we encountered the same problem some months ago (we never thought that this would happen to us wink:
). We used a PIC18F1320 as a frequency counter for flow rate sensors. Settings (for the prototype on a breadboard) were: MCLR:OFF , INTOSC: 4 MHz. We used TMR1 as a counter.
First time programming: everything OK. Then we made some software changes. Second time programming: we got the nice message "Target Device ID (0x0 or any other value) does not match expected Device ID ...". Nothing helped any more - the device could not be programmed any more. Maybe the PIC was defective? We tried another 4! Same result. Then we tried 2 PIC16F690 - same result! After a quite long research in PIC forums we found the information (from member PIC2Dev) that:
The problem occurs when the device is programmed so that:
1) It uses the internal oscillator
2) The MCLR pin is turned off to use as a digital input instead
3) The program code enabled the Timer1 Oscillator in the T1CON register. (The sooner this is enabled after the reset vector the more likely the problem is to occur.
Revival of the dead PICs: Some suggestions were to play with Vdd or simply turn MPLAB/PICkit3/PIC on and off. I have to say that with 2 PIC18F1320 this worked - after playing around suddenly they were "alive" again and could be reprogrammed - the other PICs remained dead.
Other people suggested to try to reprogram the bad PIC using "Use VPP First Program Entry" (this option can be found in MPLAB IPE or the older PICKIT2 software; programming with a PICkit3 behaving as a PICkit2). "Use VPP First Program Entry" with IPE worked for 1 other PIC18F1320 and both PIC16F690 - but after doing this procedure several times! 2 PIC18F1320 are still "dead". We did not find out why this sometimes worked and why sometimes not.
We also found explanations that when "Use VPP First Program Entry" is not set the PIC when powered ON immediately starts to run (increases the program counter) before PICkit3 or another programmer can start the programming procedure. So the programming counter is not at 0x00 but somewhere else when the programming starts.
MCLR: enable (with 10K tied to Vdd) or not did not make a difference in our case. But what we found out was that enabling Timer1 at the beginning of the software while using the internal oscillator was the main reason for the problems. Some people suggested that putting a delay (some said 40ms is enough, some said that 2sec or more are needed) before enabling TMR1 solves the problem - unfortunately not in our case.
Also there is following note in the PIC18F1320 datasheet (maybe this also applies to other PICs):
"Note: The Timer1 oscillator shares the T1OSI and T1OSO pins with the PGD and PGC
pins used for programming and debugging.
When using the Timer1 oscillator, In-Circuit Serial Programming (ICSP) may not
function correctly (high voltage or low voltage), or the In-Circuit Debugger (ICD) may
not communicate with the controller. As a result of using either ICSP or ICD, the
Timer1 crystal may be damaged.
If ICSP or ICD operations are required, the crystal should be disconnected from the
circuit (disconnect either lead) or installed after programming. The oscillator loading
capacitors may remain in-circuit during ICSP or ICD operation."
So my suggestion is to always use the "Use VPP First Program Entry"-option and to avoid INTOSC and TMR1 in the software. This is actually very annoying - you will find countless posts about this issue. Microchip should find a solution to fix this problem so it is possible to use INTOSC and TMR1 safely in an application without having mysterious effects and many lost hours for trying/searching.
I hope that this post will trigger other posts from more experienced users to put more light on this issue.