In-Circuit Debugging

[swinginguitar]

Do you guys use it? Can you give me the Cliff's notes on it?

Was looking at the Pickit 2/3 debuggers - how do they connect via those header pins if the PIC is already "in circuit"? Or do you set up a "project board" that resembles your final destination circuit but has header pins soldered to the appropriate PIC pins?

[G. Hoffman]

Do you guys use it? Can you give me the Cliff's notes on it?

Was looking at the Pickit 2/3 debuggers - how do they connect via those header pins if the PIC is already "in circuit"? Or do you set up a "project board" that resembles your final destination circuit but has header pins soldered to the appropriate PIC pins?

You loose three pins on the PIC for the debugger.  Well, probably you only loose two, unless you have the MCLR setup as an output pin.  The PGM and PCK pins are unavailable for I/O, though.  At least on the PIC16F887 I'm working with, that means you loose two pins of Port B, which I find rather frustrating, as that is the one I most want to have unencumbered.


Gabriel

[potul]

I have a pickit2 and I have never been able to make it work. I do In Circuit programming, but not debugging. I think it is related to the fact my pickit is a clone (although I've tried to apply the required fix)...
Take a look at the pickit documentation, it explains pretty well what you need, and how to decouple the pins if needed.

Mat

[G. Hoffman]

I'm in the middle of working my way through THIS, and it has section on in-circuit debugging.  I haven't gotten through that part yet, but the parts of the book I've read so far are very good.


Gabriel

[R.G.]

There are times where nothing but ICD will do. The problem I've always had is that ICD is at its worst for real-time applications. Freezing the insides and stepping them so that a human can watch means that you miss the real-time stimuli that caused the failing event.

I've had better luck with building-block implementations and well-structured code. To do this, structure your code so it's heavily modular. Got a display? Get that working first, blinking lights and in general going through its paces in response to some internal toe-counting code. When that's solid, remove the toe-counting and insert making the display respond to first one, then the other, then the other of the inputs, making sure that you force the inputs to do the odd corner conditions. When all the inputs and outputs are reliable and do what you expect for the very simple conditions that should cause them to operate, start adding the actual operating code, ideally one layer at a time. Usually this means putting in the interrupt layer(s) after all the I/Os and external pin-conditioning circuits are working right. Once interrupts are working as expected, add any operational code.

This approach has some drawbacks. It produces code that is generally reliable in practice because it forces you to consider first the things that usually trip you up, helps enforce modularity, and assists in isolating bugs by its nature. But the code is not the smallest, tightest, highest speed that can be done. My view is that unless you're an experienced uC programmer already, you have no business trying to barely fit in the smallest possible code running at the edges of the possible speed. It's far simpler to pay another $2 for a bigger, faster uC than it is to write isochronous machine language code in a spaghetti-string matrix.

It's true that real programmers program right down to the bare metal, but that is not in general what the people reading this forum need to be trying to do. Fighting it out over nanoseconds in the marketplace is a tough business to be in.

[Gurner]

I've never used ICD, but I do as a matter of course ensure there are nice chunky pads on my circuit where I can solder wires back to my pickit2 (which makes it an pseudo ICD tool of sorts)  - I just use the standalone PIckit2 app 'UART' tool, & then have my PIC spit out whatever I need to it  (ie when my program is running).

It works well.....if going this way though, try & at least leave your second to last PIC pin free (the ICSPDAT pin) solely for debug/serial out ...that pin PIC is the PIC 'TX' wire into the PICkit2 UART tool (or the Pickit's UART RX line - depends which way you want to look at it!) ....if you can't dedicate a PIC pin soley to debug, then you can implement pic function switching in your code. For example if you have a switch connected to the PIC's ICSPDAT pin, then to get debug info out of that same pin, you just quickly switch it to an output....spit out your info & then switch it back to nbe an input pin for your switch.