(Add PIC header, otherwise many people will not get your message).

The only thing that grabs me is that 20" is LONG for the ICD2 cable.
I'd suggest dropping it to 6" or less. Mine are about 5" long nominally.

I also have had ground problems caused by the fact that the ICD2 uses such
tiny wires in its RJ12 connector; try soldering a #22 or heavier jumper 
to your
development PCB and solder the other end to the ICD2. For convenience, you
can solder the GND to the metal of the USB B cable, it works good.

Make sure that the MPLAB PC and the development  PCB both use the SAME
AC Mains  branch, and ideally are on the same "power strip".

I have detected some USB issues, which seem to be eliminated when the 
Cypress chip
is not used. I prefer Kenny Wong's ICD2 USB clone to Microchip's; it 
uses a good ole
PIC chip instead of the Cypress. It also has a better connector (5-pin 
0.1" header) and
actually uses USB 5V (optional jumper) to assist in powering the unit. 
It also includes a
40P ZIF programming station at no extra cost. Yet, it costs 50% of the 
Microchip cost.
Look on EBAY for this unit, "FULL USB ICD2" or something like it. 
Shipping is only
$12 USD.

--Bob

Barry Gershenfeld wrote:
> 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