Here is a purely academic puzzle, as I've already found a solution.

I recently made a version of my PIC programmer that is intended to be built
by hand by hobbyists.  At the same time, I added labeled pads for the 5
programming signals and an RJ-12 connector so that it could program PICs in
circuit just like an ICD-2.  I finally got around to testing the RJ-12 part
this weekend and ran into a interesting problem.

As a quick test I connected the RJ-12 to a few boards that had PICs on them
and that worked with an ICD-2.  My programmer failed to read the correct ID
and couldn't program the PICs.  This led to a rather lengthy investigation
where I set up a breadboard with just a target PIC connected to the 5 lines
from the RJ-12.  It consistantly failed when the PIC was plugged into the
breadboard, but worked when the PIC was plugged into the ZIF socket on the
programmer even though all the connections to the breadboard were still
there.  The breadboard and the ZIF socket were essentially wired in parallel
in that case.  The right signals were getting to the PIC when it was on the
breadboard as verified by looking at the signals right at the PIC pins with
a scope.  These same signals were still wiggling correctly at the breadboard
when the target PIC was in the ZIF socket instead of the breadboard.  The
RJ-12 cable came with an ICD-2 (and works correctly with it) and is about 14
inches long.  My RJ-12 pigtail adapter to the breadboard is about 6 inches
long, for a total of 20 inches of wire between the RJ-12 on the programmer
and the PIC pins on the breadboard.

All tests were run at a target chip Vdd of 5V, which was verified to be
within spec.  The controller chip always runs at 5V Vdd.

PGC and PGD are driven from digital outputs of the controller PIC to the
target chip via 2Kohm resistors.  This is to deal with varying Vdd issues,
and to prevent damage when both PICs try to drive the line at the same time.
This can happen happen in an attempt to figure out the target PIC type.  For
readback, the target chip PGD is connected thru another 2Kohm resistor to
the comparator input of the controller PIC.

I tried a number of things, none of which changed the symptoms at all:

1  -  Added 10 cycles of NOP to the controller firmware before and after
clock edges.  The controller is a 16F648A running at 20MHz, so this added an
additional 2uS between edges to what was already working with the ZIF
socket.

2  -  Added 100mS of additional delay after any changes to Vpp and Vdd.

3  -  Added 100nF of bypass capacitance right at the PIC on the breadboard.
This did reduce noise at the breadboard on Vdd slightly, but had no other
noticeable effect.

4  -  Some additional pins other than the programming signals were driven in
the ZIF socket due to supporting different PIC pinouts.  None of these were
supposed to matter according to the documentation.  I hooked up all the pins
on the bread board the same way (additional connections to PGC, PGD, GND,
etc) but same symptom.  Verified on scope that all pins were in fact driven
the same as when in the ZIF socket.

5  -  Tied all remaining unused pins to ground via 10Kohm resistors.

6  -  Wrote separate host program that used only the lowest level commands
to explicitly set Vdd, Vpp, PGC, and PGD directly from the host.  There was
now at least one RS-232 command byte and a response byte between any two
transitions on any of the lines, in addition to specific longer timeouts to
make sure Vpp and Vdd stabalized.  Verified all this on scope.  At this slow
rate, signals now looked perfectly square on scope (couldn't seen edges at
all, only high and low levels).  Could clearly see time between clock and
data edges on scope at 1mS/division setting.

7  -  Added 650ohm pulldown on Vpp and 420ohms pulldown on Vdd.  This made
the fall times sharper.  The programmer regulates these voltages and this is
within its drive capabilities.  Verified that both voltages were still
regulated to well within spec of 13V and 5V when enabled.

Then I tried something that DID make it work on the breadboard with the same
software and firmware while still working in the ZIF socket.  This also
proved that everything was wired correctly and no parts were broken.  Can
you guess what it was?

Now I've got something that works, but I'm still trying to characterize it a
bit more and hopefully come up with a modification to the programmer to take
this into account.  I'll give you a chance to think about the answer while I
figure out what the production solution will be.  I'll post the explanation
and my final solution here in a day or two.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.