[Al_The_Man]

Anyone have experience with the ICD-2 as a De-bugger?
Comments, Pro's, con's?
Al.

[vegipete]

My ICD2 has worked well for me for many years up until recently. The 'problems' I experience with it now are due to it's age - it is less compatible with modern PIC's and PC operating systems.

Mine is an older one that doesn't work with Windows 7. Grrrrr. Not too terrible, I just have to maintain XP based development computers.

Many modern PIC's use a lower programming voltage. The ICD2 generates (I think) 12V levels for programming, which can fry certain chips. There are adapters and circuits available that prevent this.

Within these limitations, my ICD2 still works flawlessly but gets less frequent use now because the PICkits are adequate for most work.

Thus, like the PICkit2, if it handles your target chips and works with your computer, it is a fine tool.

-----------------
I've pondered an ICD3 from time to time but can't yet justify the price given how cheap PICkit 2 & 3 clones can be had.

[H500]

I have an icd2. I find it to be rather sluggish and it has a tendency to lock up. I often need to plug and unplug it several times before the software successfully connect to it. It works reasonably well, but the AVR Dragon for the Atmel processors worked much better.

My current project is a DSPIC based motor driver. I should probably make a bidirectional opto-isolator for it, just to be safe.

[Al_The_Man]

I have a ICD-2 clone on its way, so for $40.00 I can afford to test it, replaces the programmer also!
I will report on it after testing.
Al.

[James Newton]

See
techref.massmind.org/techref/microchip/icd2.htm for a few notes. There are certain chips that the ICD2 will fry because it's minimum VPP is more than the MAX VPP of the chip. And it CAN be made to run on Win7, but you have to do some fiddling.

[Al_The_Man]

Well I got my ICD-2 clone, after much effort the driver was loaded and I could program the chip (16F628A) but when running debugger get error ICD0083, green light and amber is on, red flashing.
No support from the supplier!
Went through the cause list and cannot see anything that stands out?
Al.

[H500]

I just got back into pic programming, so I'm no expert, but I believe your debugger was unable to communicate with the pic. Note that on the newer pics, the debug pin can be reassigned using the configurations bits. Be sure you are using the proper ones. Go to Configure-Configuration Bits. Make sure the second last item matches your connection. When starting out, I would recommend NOT reassigning the debug pins. Stay with the default until you are more familiar with the environment.

If you are using the usb version unplug the usb cable AND the mcu cable to endure that the debugger powers down. You might need to do this 5 times until it finally works. As I've mentioned before, it's very finicky.

[Al_The_Man]

It communicates with the Pic as it erases and programs, it is when I do a run and trace in debug mode that it gives the error and then hangs up Windows completely.
I believe I have set the configuration as required.
I may play tomorrow again if I get the chance.!
Al.

[vegipete]

Are you trying to debug a regular 16F628A or is it a special one with debug header? (See section 14.13 of the PIC16F627A/628A/648A data sheet.)

Do you have a bigger PIC you can test with - a 16F88x or perhaps an 18Fx520 or the like? Something that definitely has built in debug capability.

[RomanLini]

You need to debug the debugger?

Ahh the joy of computers...

[Al_The_Man]

Are you trying to debug a regular 16F628A or is it a special one with debug header? (See section 14.13 of the PIC16F627A/628A/648A data sheet.)

Do you have a bigger PIC you can test with - a 16F88x or perhaps an 18Fx520 or the like? Something that definitely has built in debug capability.

I don't have the debug header, I read the details as it being optional to free up the I/O pins, which at present I don't need as I am just debugging the USART functions.
Well I ordered an appropriate debug header, will see if that cures the problem?
Al.

[H500]

1. Did you try a chip on a breadboard? All you need is power, gnd, pgc, pgd and mclr. 2. Did you program the chip first, using Debug-Program? It won't connect without the debug code downloaded.
3. Remove any capacitor you have on mclr.
4. Are you able to read the configuration bits?

[Al_The_Man]

1 yes
2 Yes
3 no cap
4 yes.
I will have the header tomorrow and try that.
Al.

[Al_The_Man]

Well back to square one!
The header is the only thing in circuit and still the same problem, all self tests say OK, header is in a self powered socket.
The config is set to:
_CP_OFF & _WDT_OFF & _PWRTE_OFF & _INTRC_OSC_NOCLKOUT & _MCLRE_ON & _BODEN_OFF & _LVP_OFF
I previously had it set to MCLRE off but turning it on did not cure it.
A few line program to test.
It reads the chip but as soon as trying to debug, the message comes up???
Does Debug work using internal oscillator?
Al.

[H500]

I'm currently debugging a dspic with the internal osc. If there's no crystal, make sure the internal osc is selected.

[vegipete]

Try it with PWRTE set to ON.

Merry Christmas All!

[H500]

It appears that your mcu is not running. Since you can program, a simple way to rule that out is to put in a program loop to flash a led.

I can cause my icd2 to lock up by disconnecting the debug cable in the middle of an operation. After that, only a power down will will correct the problem.