New to ICSP - PIC 18F

Thread Starter

atferrari

Joined Jan 6, 2004
4,424
I expect to restart my work with PICs 18F, now using a Pickit 4. My last programmer was a Picstartplus.

a) I've been reading about ICSP. Since some of the circuits I have in mind could require using pins RB6 and RB7 I would appreciate concrete suggestions on what to implement to segregate the Pickit4 from the circuit, thinking that I will be using it for debugging as well. Regarding this last, segregation seems not to be the most appropriate, isn't it?

Please add also the /MCLR pin where I always apply a Reset button in parallel with the circuit suggested by Microchip in the datasheets.

I am looking for a non precarious solution so I can focus my attention in the programming/debugging.

Have to admit that for the moment I am at lost on what could I implement other than a string of jumpers.

b) Could anyone sumarize what should I do to simplify matters about powering the circuit with an independent PSU or via the Pickit? I feel inclined to use always an adhoc PSU.

c) What settings / connections should I change for programming / debugging?

Gracias for any help!
 

JohnInTX

Joined Jun 26, 2012
4,551
If your target will use the ICSP pins and you want to debug with them also, assign some non-critical functions to those pins so that you can use the debugger. Examples of non-critical stuff might be an LED indicator or even a non-critical pushbutton that's normally open. When you write your code, use #defines for those IO functions using those pins (I use #define for all IO definitions). Put a build-time switch in your code to relocate the normal IO to either another pin or just a bit in ACCESS RAM. That way, you can debug to your heart's content.

You can also isolate the pins so that you can have both in the circuit but since you won't get accurate operation of whatever is connected to the pin, you might as well just do some IO remapping for the debugger.

Code:
  if USING_DEBUG  ; defined in your configuration file - can also pick up MPLAB's command line parameter __DEBUG.  I prefer to explicitly set it..
DebugRAM equ 20h  ; or somewhere in ACCESS RAM

#define LED1 ,DebugRAM,6  ; when debugging, relocate RB6 and RB7 IO to RAM.  Use watch variables to see how they work
#define LED2 DebugRAM,7
 else
#define LED1 LATB,6 ; when not debugging, these get allocated to their normal functions
#define LED2 LATB,7
  endif
Note that if you have a more complex function on the ISCP pins that can't be easily redirected to RAM, you can temporarily use #defines to put them on other pins and debug them there, then move them back and just simulate their functions. Before doing all of that, though, consider a PIC with more pins, at least for development. If you have all of your IO in a definition file, you can have multiple definition files - one for the big development chip and another for the eventual target. I do that a lot.

MCLR/ Vpp can be isolated using resistors. You just need to allow the programmer to switch to Vpp without interference or delay and also protect any other stuff from the higher voltage. I've used an NPN transistor when I had a more complex RESET circuit. The RESET circuit pulls MCLR/ normally and the NPN isolates that circuit from the directly connected Vpp.

Hope that helps.
Good luck!
 

jpanhalt

Joined Jan 18, 2008
11,088
The ICSP instructions are notably vague about what's in the "isolation" box. My impression is that a resistor (4.7k or greater) often suffices between the PIC and whatever that pin is being used for. The resistor is between pin and the device, not the programmer and ICSP DAT or CLK signals. Here is one discussion on the Microchip forums: https://www.microchip.com/forums/m904754.aspx

Of course, jumpers also work, but I assume you do not want that bother. Diodes are presumably a no no.

John

Edit: Corrected lower to greater. See link for discussion of why.
 
Last edited:

Thread Starter

atferrari

Joined Jan 6, 2004
4,424
Hola John and John @JohnInTX and @jpanhalt

Thanks for the clear explanations. With 40-pin micros most of the times, I used PORTB, if a 4x4 keyboard was required (rows and columns) so I felt reluctant to do any relocation, but now I recall bringing in occasions, the columns' nibble to another port with no difficulties. So far, so good.

My last concern: for years I've been using intensively during debugging, the reset circuit below (sorry for the poor quality).

My questions: with in-circuit debugging, may I get a hardware reset via the Pickit 4 or just the PC reloaded with the start vector? If the last, how could I use, if at all, my circuit?


Reset Agustín.png
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,424
Well, the easiest way is just to not use those pins for anything else. In that case the are connected directly to the ICSP header.

Bob
OK, let's say I leave them dedicated to ICSP exclusively. How should they be set? Analog? digital, IN, OUT, high or low?
 

JohnInTX

Joined Jun 26, 2012
4,551
The reset circuit in #6 should work fine with ICSP debugging. The debugger connects directly to the MCLR/ pin. You can use the push button reset with the debugger with no issues.
 

jpanhalt

Joined Jan 18, 2008
11,088
OK, let's say I leave them dedicated to ICSP exclusively. How should they be set? Analog? digital, IN, OUT, high or low?
It doesn't matter. When the PIC is put into programming mode, those pins are automatically set to what they need to be (digital input). Same goes for MCLR. You can turn it off and use it as an input, but it becomes what it needs to be during ICSP. No worries. Microchip is a bit "bipolar" on putting a capacitor on MCLR. It helps with decoupling VCC and helps make a softer reset, but during ICSP, it can be a problem. Some datasheets suggest it; others say no. I don't give it much thought. I do what the datasheet says for my device. I usually put a small cap on it and use it as a reset only during development.

To me, MCLR serves two distinctly different purposes: 1) Resets; and 2) Putting the chip into programming mode. The needs for each differ, so a compromise is needed.

BTW, the diode is to protect Vdd and the rest of the circuit. There has been some discussion of that, and many contributors to the MCC forums favor just a resistor.

John
 

AlbertHall

Joined Jun 4, 2014
11,498
I think R8 should be zero ohms and R9 should be at least 4.7k to isolate the capacitor which otherwise might slow down the rise of VPP.
 

nsaspook

Joined Aug 27, 2009
8,659
I don't think there will be a problem driving the circuit with a modern programmer.The PICKIT3 has a 74LVC1T45 on each programming pin. That bus transceiver has >30mA drive at 5 volts.
http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf

Waveforms with a direct connect ICSP pin 1 to the capacitor.


Programming waveforms Vpp (trace 1), trace 2 ICSP pin 5

Programming end waveforms ~1ms between Vpp rise and start of data.


Rise time of Vpp at the ICSP pin on the controller board.
 
Last edited:

Thread Starter

atferrari

Joined Jan 6, 2004
4,424
It took me longer to resume my activity but on Friday I started and in no time it was up and running even working with a new micro, unknown to me, 18F2321.

Nice. Thanks to you all that replied here.

Up and running.png

20191203_150118.jpg
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,424
Congratulations. How do you like the PK4? Any way to turn off that glowing line?
Thanks John. After so many years with the PSPlus it became kind of "transparent" but very useful to me.

Looking for a way to put it "out of my way", that is, on the other side of the circuit so I can handle things with no visual obstruction.
That line, at least for now, means no even an annoyance. Will stay ON as far as I know.
 
Top