ICSP - practical anxieties

[PerranOak]

What do people ordinarily do to effect ICSP on a finished project?

I (will) have a completed project with all components soldered-in including the PIC16F1827. I have been advised that the PGC and PGD pins should not be used so that ICSP can take place: I understand why.

However, I have used all the pins.

So, what is it that I'm missing? How do people re-programme after implementation? I can think of only four things:
1. PGC and PGD are never used
2. PICs (smaller ones) are put in sockets and so sidestep the ICSP issue
3. there is some clever way of disconnecting the PGC and PGD pins from the rest of the circuit when ICSP is carried out
4. I am too thick for electronics and should take-up knitting.

Cheers.

[Ian.M]

<LOL>Definitely #4!</LOL>

More seriously .....

5. Design your circuit so that its usage of the ICSP pins on the MCU is compatible with programming.   e.g. any ICSP I/O pin used as an output shouldn't drive anything that could be damaged by the pulses that will occur during ICSP, and shouldn't significantly load the output.  Any used as an input should have a series resistor between the signal source and the pin so the ICSP programmer can drive the pin without conflicting with the signal source, which must be able to tolerate the current through the resistor.   /MCLR on PICs that use HV programming can be a particular problem as it can have up to 13.5V on it during HV ICSP. (9.5V for newer HV PICs) and any other circuits generating or sharing the external /RESET signal have to be able to tolerate that.

[fchk]

1. You really should design design your system with ICSP in mind. Adding ICSP to a system that ist not designed for it it from the beginning won't probably work.
2. You can use PGC/PGD pins as outputs in your design if your design does not put too much load onto them. You may have to use buffers.
3. You can use PGC/PGD pins as inputs in your design as long as you implement a way to disable them during ICSP (e.g. through a separate enable pin)
4. You can use shift registers to save pins.
5. Unless you have a high-volume productor are space-contraint it may be easier and cheaper to get a PIC in the next bigger package.

fchk

[mariush]

You could also just have a custom mini  programmer in your PIC from the start.
For example have just one pin always tied to ground (with a jumper or solder). If the pic starts with the pin not connected to ground, you're in "programming mode" and wait for data to come on that pin or some other pins (ex uart)

Or you could have jumpers for the two pins used for ICSP ... move jumper from 1-2 to 2-3 to program. Move back to 1-2 when you're done. Adds risk of jumpers falling, extra cost for parts.

[SteveyG]

<LOL>Definitely #4!</LOL>

More seriously .....

5. Design your circuit so that its usage of the ICSP pins on the MCU is compatible with programming.   e.g. any ICSP I/O pin used as an output shouldn't drive anything that could be damaged by the pulses that will occur during ICSP, and shouldn't significantly load the output.  Any used as an input should have a series resistor between the signal source and the pin so the ICSP programmer can drive the pin without conflicting with the signal source, which must be able to tolerate the current through the resistor.   /MCLR on PICs that use HV programming can be a particular problem as it can have up to 13.5V on it during HV ICSP. (9.5V for newer HV PICs) and any other circuits generating or sharing the external /RESET signal have to be able to tolerate that.

Exactly this, an alternative if you don't have any suitable IO is to use some multiplexers on the PGC and PGC lines that are activated when you plug in your ICSP header.

[Ian.M]

There's a further PIC specific fly in the ointment.  If the firmware uses PGC and/or PGD as normally high outputs (or on 18 pin PICs, if T1OSC is enabled on those pins) and you disable /MCLR reset, and there is a clock source (internal or external), and the board is externally powered or has a battery, you wont be able to reprogram the PIC as ICSP mode entry requires /MCLR to rise to Vpp while PGC and PGD are held low, but if power is applied before the rising edge of /MCLR the firmware runs and sets conflicting levels on the I/O pins preventing correct ICSP mode entry.

There was also a bug on really old PICs (about 25 years ago) that could result in 'off by N' addressing during ICSP.   The same hardware was used for the program counter and ICSP address counter, and if four external clock cycles occurred while /MCLR was rising, the counter would be incremented and start from address 0x001 instead of 0x000 as it was supposed to.  If /MCLR was pathologically slow rising and you had a fast external clock, it could get incremented more than once.  The solution was to ground OSC1 during programming.

[NorthGuy]

If it's already soldered in, may be you can tell us how you used these pins and what is connected to them. Also, do you have anything connected to MCLR?

[MarkF]

Here is a typical circuit from the PICkit2 User Guide.

   

[Ian.M]

That Microchip application circuit is notoriously brain-dead.  If you use a diode where shown, it does nothing to prevent Vpp (which is significantly above Vdd during HV programming) getting back to other devices sharing the same /RESET signal, and once the cap has charged it lleaves the /MCLR pin effectively floating with only its very weak internal pullup holding it high. The track to the ICSP header tends to act as an antenna so the PIC will tend to reset if an active mobile phone is brought near it! 

Also, as Microchip programmers generally aren't rated to drive a load on /MCLR of less than 5K, the 470R resistor option can  also cause problems getting /MCLR up to Vpp fast enough.

Use a 10K resistor between /RESET and /MCLR and you wont have any problems.  If whatever drives reset cant tolerate voltages greater than Vdd, add a Schottky to clamp /Reset to Vdd, as all the programmers will sink at least 1mA from Vdd which will prevent it rising even in ultra-low-power designs.  For bog-simple reset without external RC delay simply use a 10k pullup on /MCLR direct to Vdd.

[NorthGuy]

PIC16F1827 has an internal pull-up on MCLR. Thus there's no need for any MCLR circuicity. Only if you use MCLR in your design, you need to isolate it to make sure the high voltage doesn't harm other components on your board. If you don't use MCLR, enable LVP config bit and use LVP (Low Voltage Programming) - it'll be safer.

[Ian.M]

...
If low-voltage programming is enabled (LVP = 1), the
MCLR Reset function is automatically enabled and
cannot be disabled. See Section 7.3 “MCLR” for more
information.
...

You cant disable /MCLR if you are using LVP mode, and the weak pullup current can worst case be as low as 25uA,  which isn't much if the trace length to the ICSP header happens to be approximately a quarterwave in one of the GSM bands! 

For your sanity, put a footprint for a 10K external pullup, even if you intend not to populate it. 

[cv007]

A schematic would help.

Digging into one of his previous threads where a schematic was shown-
https://www.eevblog.com/forum/microcontrollers/pic-holes-in-my-project/msg2209518/#msg2209518

it shows the icsp dat/clk pins are used to drive led display segments. Since the led commons would not be driven during programming, you can simply connect the icsp connector directly to the icsp pins as there is no path through the led segments (although even driving led's from these icsp pins is not necessarily a problem- I currently have a curiosity board where an led display is using both icsp pins, one common and one a segment so get the segment blinking during programming without a problem).

That schematic also shows the MCLR pin is being used as a switch input (so must be HVP).  I assume that switch is a spdt switch (hard to tell, but is only thing that would make any sense). Since that pin can only be an input, and there is a weak pullup available, one could simply use one side of the switch- remove the connection to power, keep the connection to ground and the mclr pin (RA5), enable the weak pullup for RA5- so switch will either be unconnected to the pin where RA5 will be high from the weak pullup, or ground the pin and RA5 will be low. When programming, the switch will have to be in the non-grounding position. Now mclr will be isolated from the power and ground so can be tied directly to the icsp connector.

[Ian.M]

.... or put a 10K resistor in series with the switch common.

[bson]

3. there is some clever way of disconnecting the PGC and PGD pins from the rest of the circuit when ICSP is carried out

You can use them for things that won't conflict with ICSP, like for example an ultrabright LED that only need 25µA to light up.  If you put that on one of the PG* pins, after reset when that's still PG* before you configure it otherwise you can use it for ICSP.  You just need to be careful not to let it execute the code that reconfigures the pins.  The fact that the LED will flicker is kind of inconsequential.

Another trick is to install a 100mil pin jumper between them.  Your firmware checks for a jumper between the two pins during POR init, if there configures the pins back to PG* and halts/loops.  This way you can install a jumper, reset, and then attach the ICSP - the firmware will sit in a loop or the CPU is halted.  (Depending on CPU or what makes sense.)  When not jumpered they can be used to control LEDs, or some other use where like previously it doesn't terribly matter that they're being wiggled.

[NorthGuy]

Another trick is to install a 100mil pin jumper between them.  Your firmware checks for a jumper between the two pins during POR init, if there configures the pins back to PG* and halts/loops.  This way you can install a jumper, reset, and then attach the ICSP - the firmware will sit in a loop or the CPU is halted.  (Depending on CPU or what makes sense.)  When not jumpered they can be used to control LEDs, or some other use where like previously it doesn't terribly matter that they're being wiggled.

Only some of very old (and obsolete) PICs can interfere with programming by driving PGC/PGD pins. This is not a problem with newer ones including OP's PIC16F1827.

[PerranOak]

Blimey, thanks guys!

It boils down to the fact that I really do not want to alter the programme as I only just understand it(!) I have "designed" the PCB but not yet had it made. Then I realised that I needed to programme it in-situ once my programming skills improve. (current circuit diag attached)

What I am getting is that I've bitten-off more than I can chew. In future, I will avoid using PGC and PGD but I can't help worrying about the other components and the 13.5V. I'm still not sure if it's common to use ICSP?

What about a switch to solve all the problems? A switch with four connections (4PDT?) with one set for programming and one for running? In programme mode it could disconnect all other components.

[bson]

Another trick is to install a 100mil pin jumper between them.  Your firmware checks for a jumper between the two pins during POR init, if there configures the pins back to PG* and halts/loops.  This way you can install a jumper, reset, and then attach the ICSP - the firmware will sit in a loop or the CPU is halted.  (Depending on CPU or what makes sense.)  When not jumpered they can be used to control LEDs, or some other use where like previously it doesn't terribly matter that they're being wiggled.

Only some of very old (and obsolete) PICs can interfere with programming by driving PGC/PGD pins. This is not a problem with newer ones including OP's PIC16F1827.

Yes, but if either of the PG* pins is used for example to bit bang any of the control signals for an LCD controller, SPI device CS#, or similar, then driving them with a device programmer may cause those devices to go into all kinds of bad states.  They may end up requiring a hard power cycle to restore to normal operation, which interferes with the compile-write-run-debug-repeat cycle.