Hmmm... I can program 16F872, F627, F628 type PIC with no problems, but I
cannot program 16F628A type PICs -- I get an error that it failed to program
location 0000h. I'm using IC-Prog and a Tait-style programmer
(http://www.nomad.ee/PIC/cpp.gif). I've tried various I/O delay settings and
verified that each line to the PIC is independantly providing the correct
voltage. My Vpp is 13.3V.
I do know that the 16F628 A has a different programming protocol than the
F628, but the programmer and IC-Prog both allegedly support the F628A.
The only possible reasons I have found thru searches relates to forcing the
PGM pin low, and I am already doing that (10k resistor to ground).
PicDude wrote:
> Hmmm... I can program 16F872, F627, F628 type PIC with no problems, but I
> cannot program 16F628A type PICs -- I get an error that it failed to program
> location 0000h. I'm using IC-Prog and a Tait-style programmer
> (http://www.nomad.ee/PIC/cpp.gif). I've tried various I/O delay settings and
> verified that each line to the PIC is independantly providing the correct
> voltage. My Vpp is 13.3V.
>
> I do know that the 16F628 A has a different programming protocol than the
> F628, but the programmer and IC-Prog both allegedly support the F628A.
>
> The only possible reasons I have found thru searches relates to forcing the
> PGM pin low, and I am already doing that (10k resistor to ground).
>
I use Picallw software by Bojan Dobaj which is by the way freeware now.
You can download it at http://www.picallw.com/
"PICALLW software version 0.16 January 2005 FREEWARE"
To program 16f628a do:
1) Leave both "Erase before program" and "BlankCh. before prog." unchecked
2) Hit the Erase button
3) Then press Program button
Still no dice. And I'm certain I've programmed 627A's before as well. Some
more experimentation indicates that I have a may hardware problem, since I
also can't program a basic 16F872 now. But the individual output tests work
fine....arrggghhh!!!
I've got a few ideas to try that should hopefully narrow down the problem, but
at this point I'm moving away from software being the problem
Cheers,
-Neil.
On Sunday 20 March 2005 09:36 pm, Gaston Gagnon scribbled: {Quote hidden}
> I use Picallw software by Bojan Dobaj which is by the way freeware now.
> You can download it at
> http://www.picallw.com/
> "PICALLW software version 0.16 January 2005 FREEWARE"
>
> To program 16f628a do:
> 1) Leave both "Erase before program" and "BlankCh. before prog." unchecked
> 2) Hit the Erase button
> 3) Then press Program button
>
> That should do it for you.
>
> Gaston
Finally, I am able to program chips properly again, including 16F628A's. The
result is that I shortened the wires from the PIC programmer to the SOIC clip
and connected them directly (instead of via a programming socket adapter
board I have). I'm still trying to figure out what changed and why, but I'm
happy to be able to program chips again for now.
Cheers,
-Neil.
On Tuesday 22 March 2005 01:12 pm, PicDude scribbled: {Quote hidden}
> Still no dice. And I'm certain I've programmed 627A's before as well.
> Some more experimentation indicates that I have a may hardware problem,
> since I also can't program a basic 16F872 now. But the individual output
> tests work fine....arrggghhh!!!
>
> I've got a few ideas to try that should hopefully narrow down the problem,
> but at this point I'm moving away from software being the problem
>
> Cheers,
> -Neil.
>
> On Sunday 20 March 2005 09:36 pm, Gaston Gagnon scribbled:
> > I use Picallw software by Bojan Dobaj which is by the way freeware now.
> > You can download it at
> > http://www.picallw.com/
> > "PICALLW software version 0.16 January 2005 FREEWARE"
> >
> > To program 16f628a do:
> > 1) Leave both "Erase before program" and "BlankCh. before prog."
> > unchecked 2) Hit the Erase button
> > 3) Then press Program button
> >
> > That should do it for you.
> >
> > Gaston
> Finally, I am able to program chips properly again, including 16F628A's.
The
> result is that I shortened the wires from the PIC programmer to the SOIC
clip
> and connected them directly (instead of via a programming socket adapter
> board I have). I'm still trying to figure out what changed and why, but
I'm
> happy to be able to program chips again for now.
Interesting. There was a thread a few months back where some folks accused
the 628A of being more susceptible to noise during programming than the 628.
That sounded a little suspicious to me, but your results seem to add another
piece of data pointing in that direction.
>Finally, I am able to program chips properly again, including 16F628A's.
>The result is that I shortened the wires from the PIC programmer to the
>SOIC clip and connected them directly (instead of via a programming
>socket adapter board I have). I'm still trying to figure out what
>changed and why, but I'm happy to be able to program chips again for now.
This sounds very similar to the problem that Olin talked of a month or so
ago, as an enlargement of problems he had a while back. it seems that some
of the newer chips are more susceptible to cross talk on the ICSP lines
fouling up the replies to the programmer during verify, and he fixed it with
small (about 22pF IIRC) capacitors on both the clock and data lines at the
chip being programmed end of the wires.
Never saw that thread (but there was a recent couple-month period that I did
not receive piclist emails).
Between this and the EEPROM nightmares I had some months back with -A versions
of the 628, I am not thrilled. Not sure why I let microchip support talk me
into using the -A versions, but I ordered some regular old 628's yesterday,
albeit at a slightly higher cost.
Cheers,
-Neil.
On Thursday 24 March 2005 09:21 am, John J. McDonough scribbled:
> {Original Message removed}
I must try that. Unfortunately in my desperation to get the programmer
working, I hacked most of it apart. Hoping to get some time this weekend to
re-build it and I'll try the caps as well.
I'll post my results then.
Cheers,
-Neil.
On Thursday 24 March 2005 09:49 am, Alan B. Pearce scribbled:
> This sounds very similar to the problem that Olin talked of a month or so
> ago, as an enlargement of problems he had a while back. it seems that some
> of the newer chips are more susceptible to cross talk on the ICSP lines
> fouling up the replies to the programmer during verify, and he fixed it
> with small (about 22pF IIRC) capacitors on both the clock and data lines at
> the chip being programmed end of the wires.
>> This sounds very similar to the problem that Olin talked of a month or so
>> ago, as an enlargement of problems he had a while back. it seems that some
>> of the newer chips are more susceptible to cross talk on the ICSP lines
>> fouling up the replies to the programmer during verify, and he fixed it
>> with small (about 22pF IIRC) capacitors on both the clock and data lines
>> at the chip being programmed end of the wires.
> I must try that. Unfortunately in my desperation to get the programmer
> working, I hacked most of it apart. Hoping to get some time this weekend
> to re-build it and I'll try the caps as well.
Adding the caps on the programmer end does not fix it.
Problem, as I understand it, is the newer chips (particularly dsPIC)
have such fast rise times that the PIC presentation of a data bit on the
PGD line induces a glitch on the PGC line. The PIC being programmed sees
the extra transition on the PGC as a clock pulse and the PIC gets out of
sync with the programmer.
Advice was to add a 20'ish pF cap on each of PGC & PGD lines at the
target board end. Addition of a low ohm (100 ohms?) resistor in series
with one of the lines (I think PGD but am not sure) was also advised.
Since it's the target board generating noise that effects the target,
you have to have the components on the target board. Adding them to
the programmer doesn't help. If you're laying out a new board, put
pads in for SMT caps near the programming connector. Then populate
them only if you run into the problem. It's nearly free insurance.
Standard things... Keeping the cable as short as possible helps.
The silver satin wire used by Microchip on the ICD2 doesn't help at
all since the wires are parallel to each other. I've built cables
using twisted pair cable (UTP). Put PGD & ground on a pair, put PGC
& ground on another pair; physical seperation & grounds help reduce
crosstalk. Getting the multiple grounds hooked up at the RJ12 plug
end is the hardest problem. Much easier to build the cable if you
have a SIP header at the programmer end (see Olin's ProProg).
> Adding the caps on the programmer end does not fix it.
> (snip)
My Wisp628 has always had series resistors in all lines from the
programmer to the target (except power and ground). Once I used 470
ohms, nowaydays 47 ohms. The resistors are in the programmer. I recall
Vasile Surducan once reporting problems that were cured by putting 22pF
or something like that on clock and/or data pins near the target, but
otherwise I have yet to hear of any crostalk-like problems. I have used
both standard ribbon cable and standard DB15 extension cable up to a few
meters between the programmer and the target, without problems. So you
might try to use series resistors. But note that this might affect the
data and clock timing.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
On Thu, 2005-03-24 at 23:01 +0100, Wouter van Ooijen wrote:
> > Adding the caps on the programmer end does not fix it.
> > (snip)
>
> My Wisp628 has always had series resistors in all lines from the
> programmer to the target (except power and ground). Once I used 470
> ohms, nowaydays 47 ohms. The resistors are in the programmer. I recall
> Vasile Surducan once reporting problems that were cured by putting 22pF
> or something like that on clock and/or data pins near the target, but
> otherwise I have yet to hear of any crostalk-like problems. I have used
> both standard ribbon cable and standard DB15 extension cable up to a few
> meters between the programmer and the target, without problems. So you
> might try to use series resistors. But note that this might affect the
> data and clock timing.
I don't know about other chips, but the 30F2010, in at least certain
revisions, does need this, even with an ICD2. TTYL
Lee Jones wrote:
> Advice was to add a 20'ish pF cap on each of PGC & PGD lines at the
> target board end. Addition of a low ohm (100 ohms?) resistor in
> series
> with one of the lines (I think PGD but am not sure) was also advised.
It was the PGD line, and the resitor goes between the PIC and the cap. This
provides additional filtering to remove high frequencies from what is driven
over the PGD wire back to the programmer.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
>>> This sounds very similar to the problem that Olin talked of a month or so
>>> ago, as an enlargement of problems he had a while back. it seems that some
>>> of the newer chips are more susceptible to cross talk on the ICSP lines
>>> fouling up the replies to the programmer during verify, and he fixed it
>>> with small (about 22pF IIRC) capacitors on both the clock and data lines
>>> at the chip being programmed end of the wires.
>
>> I must try that. Unfortunately in my desperation to get the programmer
>> working, I hacked most of it apart. Hoping to get some time this weekend
>> to re-build it and I'll try the caps as well.
>
>Adding the caps on the programmer end does not fix it.
>
>Problem, as I understand it, is the newer chips (particularly dsPIC)
>have such fast rise times that the PIC presentation of a data bit on the
>PGD line induces a glitch on the PGC line. The PIC being programmed sees
>the extra transition on the PGC as a clock pulse and the PIC gets out of
>sync with the programmer.
>
>Advice was to add a 20'ish pF cap on each of PGC & PGD lines at the
>target board end. Addition of a low ohm (100 ohms?) resistor in series
>with one of the lines (I think PGD but am not sure) was also advised.
>
>Since it's the target board generating noise that effects the target,
>you have to have the components on the target board. Adding them to
>the programmer doesn't help. If you're laying out a new board, put
>pads in for SMT caps near the programming connector. Then populate
>them only if you run into the problem. It's nearly free insurance.
If the programmer's output clock line was low impedance, this wouldn't
happen, right?
>Standard things... Keeping the cable as short as possible helps.
>
>The silver satin wire used by Microchip on the ICD2 doesn't help at
>all since the wires are parallel to each other. I've built cables
>using twisted pair cable (UTP). Put PGD & ground on a pair, put PGC
>& ground on another pair; physical seperation & grounds help reduce
>crosstalk. Getting the multiple grounds hooked up at the RJ12 plug
>end is the hardest problem. Much easier to build the cable if you
>have a SIP header at the programmer end (see Olin's ProProg).
>
> Lee Jones
>
ThePicMan wrote:
> If the programmer's output clock line was low impedance, this wouldn't
> happen, right?
No, since the whole effect can happen in the propagation time of the data
signal from the target chip to the programmer and back. Anything you do at
the programmer end of the cable can't possibly make a difference during this
time.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
> If the programmer's output clock line was low impedance,
> this wouldn't
> happen, right?
The effect is caused by the rise time of the 'source' line, combine with
the high impedance (only at the target side?) of the other line. A
series resistor softens the rise time, and damps ringing. A capacitor
softens the riste time, and (when placed at the target) provides a
low-impedance.
A low impedance of the clock output driver can only worsen the effect.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
Agreed. The series resistor softens the wavefront, reducing the
radiation effects to the nearby wiring.
The PIC has a Schmitt-triggered input in program mode, so the
R won't prevent proper operation even when it is larger. An R of
100 ohms should be right.
The RJ12 of the ICD2 is a problem, as the wires are bundled too
tightly.
>>If the programmer's output clock line was low impedance,
>>this wouldn't
>>happen, right?
>>
>>
>
>The effect is caused by the rise time of the 'source' line, combine with
>the high impedance (only at the target side?) of the other line. A
>series resistor softens the rise time, and damps ringing. A capacitor
>softens the riste time, and (when placed at the target) provides a
>low-impedance.
>
>A low impedance of the clock output driver can only worsen the effect.
>
>Wouter van Ooijen
>
>-- -------------------------------------------
>Van Ooijen Technische Informatica: http://www.voti.nl
>consultancy, development, PICmicro products
>docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
>
>
>
Getting back to this old thread, now that I'm back home for a bit, I tried the
caps/resistors, but it did not solve the problem for me. However, I did find
a problem...
Short answer is that the ribbon cable and SOIC test clip attached in parallel
to the ZIF programming socket was causing the problem, but I'm still not sure
why, since I verified no shorts/opens and voltages at the appropriate pins
were fine.
Long version...
My programmer is a Tait parallel programmer with a jumper at the output. This
jumper is then connected to one of a few headers which routes the programmer
output to the appropriate PIC pins, based on the type of chip to be
programmed. This photo may clarify this a bit... http://www.narwani.org/neil/electronics/TaitProgrammerNew.jpg
There is a 28-pin zif socket that the PICs fit into. There is also a 28-pin
SOIC test-clip wired in parallel to the socket, so I can program either
package type. This is connected with 2 pieces of 14-conductor ribbon cable.
When I had the problem, the pins on the SOIC test clip and on the ZIF socket
tested fine, but I could not program the 16F628A-SO's. Apparently there were
intermittent problems programming the DIP version as well. It would work
sometimes, but not always.
After I de-soldered the ribbon cables from the programmer board, I can program
DIP versions of the F628A properly. I re-soldered the ribbon cables with the
SOIC test clip, tested thoroughly and verified no shorts, opens, etc, but it
would still not program the F628A-SO, and had intermittent probs with the DIP
version again.
Last thing I tried was to remove the ribbon cable and just route 6 wires from
the DIP socket to the SOIC test clip, and I can program the SOIC version
again.
I'm still unsure why this would happen.
Cheers,
-Neil.
On Thursday 24 March 2005 10:13 am, PicDude scribbled: {Quote hidden}
> I must try that. Unfortunately in my desperation to get the programmer
> working, I hacked most of it apart. Hoping to get some time this weekend
> to re-build it and I'll try the caps as well.
>
> I'll post my results then.
>
> Cheers,
> -Neil.
>
> On Thursday 24 March 2005 09:49 am, Alan B. Pearce scribbled:
> > This sounds very similar to the problem that Olin talked of a month or so
> > ago, as an enlargement of problems he had a while back. it seems that
> > some of the newer chips are more susceptible to cross talk on the ICSP
> > lines fouling up the replies to the programmer during verify, and he
> > fixed it with small (about 22pF IIRC) capacitors on both the clock and
> > data lines at the chip being programmed end of the wires.
It looks to me as though the ribbon cable was presenting too much
of a capacitive load to the driver circuits on the programmer board.
Also, the ribbon may have been introducing excessive crosstalk
between pins. Going to the separate wires soldered point-to-point
would be likely to have lower capacitance and maybe lower cross-
talk as well,
narwani.org>
