I have developed several products using in-circuit programming of PICs without any problems.  However, the latest product is causing problems:
 
The design uses a PIC16F876A running at 3.3V.  The PGC and PGD pins are dedicated solely for programming, and MCLR has a 10K pull-up, but is also taken to the programming socket.
 
My problem is that although on occasion I have been able to use ICD2 to program and/or debug the product, most of the time programming fails, reporting memory locations as holding a value of 0x000 instead of the required value.  If I erase the device through ICD2, MPLAB says the erase has succeeded, but if I then verify that the device is blank it fails, saying address 0x0 reads a value of 0x0 instead of 0x3FFF.  If I read the device all locations read 0x00.
 
ICD2 correctly recognises the target device as a PIC16F867A, revision 0x8. 
 
I know from previous experience that there are issues using in-circuit programming at 3.3V (particularly that Code Protection cannot be re-programmed at less than 5V, so if it is set there is no way of programming at 3.3V).  However, my design is 5V tolerant, so I have tried configuring ICD2 to power the target. ICD2 then passes self-test and shows valid level on the target Vdd (4.8V), Target Vpp (12.6V) and MPLAB ICD 2 Vpp (12.7V), but programming still fails, with memory contents reading 0x00.
 
I have watched PGC and PGD on a scope while attempting to program (inside the ICD2 to confirm no problems with the connecting cable), and they have valid data levels.  I have tried two different ICD2's (both of which work on other products), and I have run MPLAB on two different computers.  I have also tried four different targets, but I get the same results every time.
 
I can unplug the ICD2 from the new product and plug it instead into a different target that uses a PIC18F252 running at 3.6V, then change the project on MPLAB, and I can program it using power from either the target or from the ICD2.
 
I am running out of ideas. Can anyone offer any suggestion why I should have this problem?
 
Regards

I have exactly the same problem with my PICDem board using 18f4520. When I use ICD2 for programming, it succeeds but verification fails (all memory after address 1000 is read 0x0000). All voltage levels are OK, short cable between ICD2 and target. Same problem when erasing the device. All 0xFFFF up to address 0xFFF but at address 0x1000 and above all zeros.
 
Programming and easing works well with a different programmer so I assume the device is OK.
 
When I google I get the impression that this is not an uncommen problem. Any other idea than above what can be checked?

I had a similar problem. Once I included a linker script in the project, the problem went away.

Thanks for feedback. I have included linker scripts (18f4520.lkr for release and 18f4520i.lkr for debug build) but this didn't help. the strange thing is that programming works well with a different programmer, therefore I assume electrical problems.
 
RB5 and RB6 are only connected to ICD, MCLR has a 10k R to Vdd. Vdd measured is 5.15v, Vpp programmer is 13.1V, Vpp target is 9.4V.
 
To me this seems OK.

It happened to me once to. I replaced the 10k on MCLR with a 4.7k. All went well after that...

Since posting my problem I discovered the cause:

The target board has a 3.3V regulator on the power supply.  I know from past experience that you cannot program a Flash PIC at a supply less than 5V if Code Protection is set, so I configured ICD2 to power the target and the ICD Setting confirmed that the power supply was 5V.

However, I had overlooked the fact that the 3.3V regulator was between the PIC and the ICD2 connector, so although I was feeding 5V to the board the processor was only running from 3.3V.  Coupled with this I had downloaded a configuration that set the Code Protection bit.

I cut a track and fitted a wire link so the ICD2 connector on the target was directly connected to the PIC and the problem was solved.

A.R. --thanks for following up and posting your problem resolution.
 
I'm going to pin this to the top.  It may help others with a similar problem.

As I said, I knew of the problem from past experience:

Some time ago I developed a product using a PIC with a radio modem chip.  The maximum allowable supply to the radio was 4V, so the system ran from a 3V battery.  I inadvertently programmed some of the devices with Code Protection set.  When I subsequently tried to re-program them I couldn't.  Furthermore I couldn't use ICD2 power to raise the supply to 5V since this would damage the radios.  The PIC's were SMT devices, so we had no option but to unsolder them from the boards and replace them.

Remembering the amount of work incurred then I should have spotted earlier that the problem I excountered recently had the same symptoms!

liufang898186

Excellent list! I've learned more from this forum in about 2 days than I have at any other forum community.

argh! getting wiser and wiser!!

Yup I had the same issue once, it was code protected to :)