PIC ICSP Programming Circuit

[NorthGuy]

For PIC16F88, you need to make sure the PGM pin is tied down (through a resistor or driven by the programmer), even if you only use HVP programming.

[MarkF]

I tend to disable the "Low voltage programming" in the PIC fuses
and set the PGM pin as I/O.

I only use "High voltage programming".

Then just add a simple jumper between the PIC/ICSP and the rest of your circuit.
With the jumper, you can then switch between "programmer powered" and "circuit powered".
This way you can have the PCB manufactured, program the PIC and then solder a jumper for delivery/testing.

[NorthGuy]

I tend to disable the "Low voltage programming" in the PIC fuses
and set the PGM pin as I/O.

When you program the device, the programmer does bulk erase first. This restores the default LVP=ON setting. If the programmer resets the PIC while in this state, and PGM is high, the PIC may enter LVP mode causing the programming to fail. Not all PICs with PGM pin are vulnerable to this, but many are.

[MarkF]

I tend to disable the "Low voltage programming" in the PIC fuses
and set the PGM pin as I/O.

When you program the device, the programmer does bulk erase first. This restores the default LVP=ON setting. If the programmer resets the PIC while in this state, and PGM is high, the PIC may enter LVP mode causing the programming to fail. Not all PICs with PGM pin are vulnerable to this, but many are.

If you are doing 'High Voltage Programming', is this even possible?
Wouldn't that prevent you from ever disabling LVP?

[MarkF]

Not sure.  But it looks like the OP is using a pic16f648a.
According to the Errata, the state of the PGM pin during 'High voltage programming' doesn't matter.



For safety, put a 100KΩ resistor to GND on the PGM pin. 
That size resistor will not impact the rest of the circuit if you want to use the PGM pin.

[girishv]

Not sure.  But it looks like the OP is using a pic16f648a.
According to the Errata, the state of the PGM pin during 'High voltage programming' doesn't matter.

The MCU in question is PIC16F684, not PIC16F648A.

[Ian.M]

Life's too short to wade through Microchip's (incomplete) errata, and anecdotal evidence on their forum to figure out exactly which of the early LVP capable PICs can be affected by glitches or high levels on PGM at HV programming mode entry, or while HV programming  is in progress.

In all cases, if a PIC has a seperate PGM pin for LVP mode entry, wire it to pin 6 (AUX/LVP) of the ICSP connector, and if the target board is capable of driving it with a 'stiff' logic '1', add an isolation resistor between it and the rest of the target board.  Ensure HV programming is selected in whatever software your programmer uses, and simply let the programmer handle it.

The fuse to disable LVP programming cant be disabled in LVP mode.  If its left enabled, you cant disable /MCLR or use the PGM pin for I/O.  Also a floating PGM pin at runtime can cause unwanted LV Programming mode entry, which if its brief enough has apparent symptoms closely resembling an unintended device reset.

[MarkF]

Not sure.  But it looks like the OP is using a pic16f648a.
According to the Errata, the state of the PGM pin during 'High voltage programming' doesn't matter.

The MCU in question is PIC16F684, not PIC16F648A.

The pic16f684 doesn't have a PGM.  So, this discussion is mute.
I mentioned the pic16f648a because you said it might be a replacement with a PCB design change.

Life's too short to wade through Microchip's (incomplete) errata, and anecdotal evidence on their forum to figure out exactly which of the early LVP capable PICs can be affected by glitches or high levels on PGM at HV programming mode entry, or while HV programming  is in progress.

It's just good engineering practice to 'wade' through the manufacture's documentation for the device you're using.  Complete or not.  The more you know about a device the better.  Why leave it to 'Murphy'?
If it's for a personal project, then by all means roll-the-dice.

[Ian.M]

Yes,its good practice to read  the documentation and all relevant errata, and absolutely essential for commercial product development,  but when the 'smoking gun' that there is probably a hardware issue is *NOT* in the errata but is buried in a several years old forum thread where it was admitted off-the-cuff by a Microchip 'staffer', if you don't have sufficient background to remember that forum thread, you'll be rolling-the-dice anyway, without even realising it.

I'd be much more impressed with Microchip if they'd implement a hardware bug-tracker, updated by level two and higher support and the chip development teams, and publicly searchable and viewable.   (Not publicly or level one support updatable to prevent it being spammed with non-bugs by numpties!)

[girishv]

Not sure.  But it looks like the OP is using a pic16f648a.
According to the Errata, the state of the PGM pin during 'High voltage programming' doesn't matter.

The MCU in question is PIC16F684, not PIC16F648A.

The pic16f684 doesn't have a PGM.  So, this discussion is mute.
I mentioned the pic16f648a because you said it might be a replacement with a PCB design change.

  It was a typo. I am sorry for creating confusion. The chip used is PIC16F684.