Olin, I have been experiencing the exact same problem, as I wrote in the other thread about 'Using The DIYK128 In An ICSP App'. Of course, your description of the problem is far more precise and lucid. The suggested cure from Bob and Outer was to add ample decoupling at the breadboard end of the cable. This improved the operation quite a bit, but its still nowhere failsafe. I also noticed that the failures were more consistent with 8 pin devices as against the larger PICs. So, I am very very curious to know what finally solved the problem. Regards, Anand Dhuru ----- Original Message ----- From: "Olin Lathrop" To: Sent: Monday, February 09, 2004 4:27 AM Subject: [PIC]: PIC programmer puzzle > 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. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.