pic 16F819 will not program

[Niels Damsgaard-Sørensen]

Hi group. Before i'm pulling out all my hair (still a bit left), i better
ask for some advice here:
I'm working on two different boards, both with a'n Pic 16F819 SOIC. I have
made a lot of these boards earlier, programming onboard with a Picstart.
This time i made up 20 of each and started programming the same o'l Hex to
the boards, but nothing semed to work. Took the whole lot with me home for
the weekend and tried my own ICD2. Same result :-( Problem seemes to be,
that all chips are write/code protected. Im sure i made the fusesettings in
MPLAB right, no fusesettings in software. In Microchips errata it says these
chips can be difficult, in the Picstart helpfile in MPLAB it says : add a 1k
pulldown to MCLR. Could failing to do so cause the chips to be
code-protected ? And should i not be able to remove ALL fuses with a general
erase?
Any ideas ?

Niels

 

[Spehro Pefhany]

Hi group. Before i'm pulling out all my hair (still a bit left), i better
ask for some advice here:
I'm working on two different boards, both with a'n Pic 16F819 SOIC. I have
made a lot of these boards earlier, programming onboard with a Picstart.
This time i made up 20 of each and started programming the same o'l Hex to
the boards, but nothing semed to work. Took the whole lot with me home for
the weekend and tried my own ICD2. Same result :-( Problem seemes to be,
that all chips are write/code protected. Im sure i made the fusesettings in
MPLAB right, no fusesettings in software. In Microchips errata it says these
chips can be difficult, in the Picstart helpfile in MPLAB it says : add a 1k
pulldown to MCLR. Could failing to do so cause the chips to be
code-protected ? And should i not be able to remove ALL fuses with a general
erase?
Any ideas ?

Niels

Protection on the F parts doesn't stop you from erasing the chips and
programming them. Could they be in LVP mode? Try a 1K pulldown on PGM.

BTW, whatever problem it was with the flash does not appear on the
current errata. I wonder where Microchip squirrels away the older
errata sheets? I ran into a problem with the 16F628 (buggy CCP module)
that could have used an errata sheet that matched my samples (only a
year and a half old).

Best regards,
Spehro Pefhany

 

[Niels Damsgaard-Sørensen]

Thanks for your help Spehro - but:
Tried that. Did that. No luck.
Still on verifying it states: Config bit errors .....
I have erased, resat, etc. a thousand times but with the same bad luck. By
the way - all my machines are now running XP.
Last time i did this i think it was 98 on the labtop?
Just programmed some DIL 16F877 with a simple "blink a LED". Both
programmers works fine.
I think i know one customer who's gonna blow a fuse tomorrow.
Niels

 

[Niels Damsgaard-Sørensen]

I got it !!
In the MPLAP helpfile for Picstart it says that when programming 16F818
/19's you must use a 1K from MCLR to GND! It must be a pullUP !!
What really tricked me was all the "helpfull" errormessages in Mplab, saying
that it erased and that config bits was like this and like that. Only when i
tried erasing, programming and reading without any pic connectet, and still
got the same message about "read" config bits and protected memory i
suspected that the programmer was not talking to the pic at all.
I guess you guys all knew about this, but to a non-educated fool like me,
this sort of help is not helpfull at all :-((

When i get elected king of Sweden, Microchip WONT be in for a Nobelprice for
this one.

Niels

 

[Gary Morton]

I got it !!
In the MPLAP helpfile for Picstart it says that when programming 16F818
/19's you must use a 1K from MCLR to GND! It must be a pullUP !!

So do you need a pulldown to gnd or a pullup to vdd?

What really tricked me was all the "helpfull" errormessages in Mplab, saying
that it erased and that config bits was like this and like that. Only when i
tried erasing, programming and reading without any pic connectet, and still
got the same message about "read" config bits and protected memory i
suspected that the programmer was not talking to the pic at all.
I guess you guys all knew about this, but to a non-educated fool like me,
this sort of help is not helpfull at all :-((

When i get elected king of Sweden, Microchip WONT be in for a Nobelprice for
this one.

Niels

I have a board with two PIC16F819s which are both programmed using a header
for ISP. They both used to program OK, but now one still programs but the
other does not. I was going to unsolder (surface mount) and replace, but I
will try your suggestion of pull up/down.

Thanks for raising this issue

--Gary

 

[The6502man]

So do you need a pulldown to gnd or a pullup to vdd?

I would assume pull up, since MCLR is an active low reset pin. I
usually use a 4.5K or so myself.



Tony

 

[Al Klein]

Gary Morton wrote:

I would assume pull up, since MCLR is an active low reset pin. I
usually use a 4.5K or so myself.

I have a 16F84 that does the same thing. Pull MCLR up and it won't
erase or program. Pull it down and it does. Since the board has MCLR
pulled up I had to add a pulldown on the programmer.

 

[Niels Damsgaard-Sørensen]

I have a 16F84 that does the same thing. Pull MCLR >up and it won't

erase or program. Pull it down and it does. Since the >board has MCLR
pulled up I had to add a pulldown on the programmer.

Point is, that Microchip specifically say about the 16F818/9 that it is
special because that it needs a 1K pull_down_.
AND (in my case anyway) it should be a pull_up_.
Before i read this, i used nothing and found, that the chips was a bit
unstable to program, but it worked. (I did actually unsolder a few soic
Pic's because they did'nt work and i suspected i had fryed them by
accident.) Then i found their corrections mentioning the pulldown and then
_nothing_ worked. And again i unsoldered some chips before i (by accident)
tried the pullup. Offcourse i'm the one to blame because i just did as i was
told without thinking myself, but you know, i thought Microchip know about
their own products so i looked everywhere else for the cause of my problems.
And the various errormessages in Mplab kept me from suspecting the actual
download-process causing the problems.

Niels

 

[Al Klein]

tried the pullup. Offcourse i'm the one to blame because i just did as i was
told without thinking myself, but you know, i thought Microchip know about
their own products so i looked everywhere else for the cause of my problems.

A pullup allows the uProcessor to start running as soon as the
programming is complete. A pulldown prevents it from running.
Neither one should have any effect when the programming pin is made
active. That's just my opinion.

And the various errormessages in Mplab kept me from suspecting the actual
download-process causing the problems.

Someone's learning from uShaft? (How to write totally meaningless
error messages?)

 

[Johan]

try the following connection for /MCLR

Vdd- 10k - | - 1n4148-> - /MCRL
| - 10uF - gnd

In this the how Microchip suggest in their ISP-guide. Works everytime

/Johan