>
>
>- first of all, we don't even use the ICSP module.  We just use the zif
>   socket adaptor (AC164012 in our case), and a homemade cable to the
>   target board.  During one of the times we were having problems, it was
>   decided that the "official" ICSP module was the cure, so we bought one.
>   Never did get it to work reliably, and didn't have time to figure out
>   why.  So it now lies in a heap in a corner somewhere.  Knowing what we
>   learned since, it should probably be looked at again.


That's a cheerful thought.
These protos are SMD, and MUST be programmed in-system.


>- unless you've isolated it somehow, the promate has to supply the 5V
>   requirement for the whole board, not just the pic.  We've run into
>   problems with target boards with heavier 5V supply requirements.

Not a problem here the whole target only draws 3mA, and most of that is the
pic.


>- related to that, the promate uses a Raychem polyswitch (or similar)
>   type of device for current/temp protection that is too conservative in
>   our opinion (downstream of the 78xxx regulator).  So we've bypassed it
>   on all of our promates.

I don't think they're going to run it tight enough to kill me.


>- I don't know if this applies to your target chip, but we use the F87x
>   and find that we have to ground RB3 when in-circuit programming a chip
>   that hasn't ever been programmed.  This whole subject has been dicussed
>   extensively on the piclist - I can attest that the problem is real.

I've hit this too, but these chips have been programmed previously.
I've gotten a few successes, and way more failures, which tells me it's in
the programming system, not the target.

>- a false code protect error is what the promate will give if you try
>   programming with nothing attached.  Nearly every time we get a code
>   protect error, it is because of a connection problem.  For example, we
>   use 8 pin phone jacks for the board interface, and have had problems
>   with conformal coating getting in where it doesn't belong and
>   interfering with the spring loaded pins.  Also once saw the RB6 pin
>   lifted on a surface mount device.  Incidentally, if the device is truly
>   code protected, the promate will allow you to go ahead and program
>   anyway.

Not likely, a problem here..
I AM however, seeing RB7 only achieving 1V during programming. Not sure
who's causing that.


>- verify your target board design - we also discovered that we were
>   designing our target boards incorrectly.  We were only putting a diode
>   between /MCLR and Vdd to  isolate the 5V supply from Vpp.  However, the
>   promate (any programmer, actually) needs to hold /MCLR low to reset the
>   chip.  Without a resistor in addition to the diode, this shorts the 5V
>   supply.  Amazingly, the promate still managed to program these boards.
>   Watching the process on a scope showed that the 5V supply drooped
>   dramatically, which must have been low enough to get the pic reset -
>   seems a nasty  way to treat the promate though!

10k resistor here, they BETTER be able to drive that.



>The two most important things for us were bypassing the promate's internal
>protection and paying attention to RB3.

Hmmm.



--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

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