I am having trouble with my ICD2, not unlike Shawn's troubles, but I think 
my problem's different.  For one thing, I'm working with 18F chips rather 
than 12F.  For another, this thing used to work.  I'll go into details 
shortly, but I'm thinking I should try whatever signal conditioning tricks 
as may have been recommended in the past (and which I never needed 
then).  I can't seem to turn up much by searching.

The symptom is  "Target not in debug mode" "Unable to run target",  "Unable 
to enter debug mode", and all those familiar assocated errors.   I can step 
a few times but then it chokes.  Or if I run and hit "stop" it 
chokes.  Usually I can run to a breakpoint and keep in sync.

OK, so I can tell you the following...

I have been using the ICD2 since it came out.  (And ICD-1 before that!)
I have made (my EE's, actually) many different boards, and brought them up 
and done FW for  them using 12F, 16F, and 18F, all using this ICD2.
I have made about every possible mistake 2 or three times (well, the non 
fatal ones anyway)
I have several ICD cables that I can swap.
The cables are 20" (.5m) or less.
I actually have 2 ICD's here and the other acts the same.
I can swap boards under test and the problem persists.
This started when I upgraded both the (CCS-C) compiler and MPLAB
I blamed MPLAB, downgraded it, and the problem went away.
Then I tried the same thing with the compiler, and the problem went away.
Then I tried an assembly language program (MPASM) and the problem went away.
Then I started coming up with workarounds... (like run to breakpoint 
instead of hitting 'stop')
Reset (the hockey puck icon) Always works.  Then I can step or run until it 
"gets lost" again.
Straight "program" is always successful.  Target runs when ICD disconnected.
Debug program + RSBUG etc is always successful.
Today we are using the target's power.  I have tried it both ways.
Box Axtell suggested upgrading to MPLAB 7.4  I went to 7.42.  Things 
improved...a bit...for a while...

I keep finding 'smoking guns' but they don't seem to lead anywhere.

Right now, I've found another one.  I have an 18F4455 pretending to be a 
mouse (you know the drill).  If I set the "PLL Divider" to 1 (it's a 4 MHz 
osc.) I get the bad behavior described above.  But if I change it to 3 
(presumably all the clocks are now slower) it is rock solid.  I can even 
let it step through time delays or i2c driver sequences and it doesn't 
hiccup at all.  (Those are particularly annoying but I finally found a use 
for them: they give you a lot of time to tweak the 'scope display while 
they are stepping.)

So I'm thinking it's a timing issue.  I took a look at RB6 and RB7, with 
RB6 being the more active one.  Everything looks reasonable, except for 
some overshoot on the signals.   You can see what I saw, at 
http://www.kdcomm.net/~barry/postit/pic_icd/   You'll also see one or two 
other suspicious things that could be normal for all I know.

So, maybe some resistors or capacitors are the answer?

Barry

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist