Searching \ for '[PIC] Programming failures on 16lf819 parts?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Programming failures on 16lf819 parts?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Programming failures on 16lf819 parts?'
2007\06\12@095733 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anyone else had bugs where writing a specific firmware to a PIC would
prevent it from being programmed again? And I don't mean code protect
stuff, I am doing a full voltage erase, and code protection was never
enabled in the first place.

Basically I've found that on 16lf819's (tried with SO package only)
after burning certain firmware versions to them any further attempt to
erase the device fails and does absolutely nothing. Yet, if I burn a new
firmware version to it, while the erase fails, the firmware appears and
then the chip works just fine. Even weirder is I haven't been able to
track down a "known-bad" firmware, after burning a "good" firmware in
successfully suddenly everything is working again, even what I thought
were bad firmwares. At the same time, sometimes what I thought was a
"good" firmware version is "bad" It's more that if I try burning a
*different* firmware to the chip, I'm pretty much guaranteed for it to
start working again.

Also if I wait a day, burning works fine again, for about twenty or so
burns.

I've ruled out stacks of issues, this problem appears on two different
programmers, different computers, after reboots, on bare chips or in
circuit, PGM low, high, floating whatever, temperature, body oder etc.

I checked the errata sheets. I think my PICs, which according to pk2 are
"Rev 5" aren't even covered by the errata's, which are for "Rev A4" and
"Rev B0"


Ideas?

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGbqYv3bMhDbI9xWQRAt3MAJ4/KmWfHRp8NjFN/5P58MM8wU9mVwCdFdRc
cxEKmUjTt7zS4RyE8rVU2mo=
=NS0L
-----END PGP SIGNATURE-----

2007\06\12@111214 by Alan B. Pearce

face picon face
>Also if I wait a day, burning works fine again,
>for about twenty or so burns.

This strikes me as a problem with LV programming bit being set, and the PGM
pin not being held in the correct state.

What programmer are you using? I seem to remember someone recently having a
problem where they found their programmer was illegally changing some bits
in the config word from what was specified, and doing something like this.

2007\06\12@114520 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jun 12, 2007 at 04:12:08PM +0100, Alan B. Pearce wrote:
> >Also if I wait a day, burning works fine again,
> >for about twenty or so burns.
>
> This strikes me as a problem with LV programming bit being set, and the PGM
> pin not being held in the correct state.
>
> What programmer are you using? I seem to remember someone recently having a
> problem where they found their programmer was illegally changing some bits
> in the config word from what was specified, and doing something like this.

The problem appears with both a PICStart+ clone and a PICKit2...

That said, sure enough I found it. Turns out the errata was applicable,
namely that switching to the internal oscillator to 8mhz too soon
actually causes the oscillator to overshoot, resulting in an out of spec
condition. This didn't seem to affect my app at all, but it did cause
programming to fail. Adding a half second delay at the very top of the
program fixed the issue. Anything I did after the oscillator switch had
no effect, for instance an infinit loop directly after the switch to
8mhz still failed, which the same infinit loop, with a five second delay
before the switch worked fine.

What's really weird is it took a good 6 months of on and off development
to even run into the problem. Yet I the code to switch to 8mhz was in
there from the very start, and indeed was copied from another 16lf819
using project.

Even weirder though was I was trying some months old firmware versions
out, that now suddenly, and reliably, have the problem! It's like
running into it once in a day causes the programmer, even after being
turned off, to trigger it even with firmware that previously worked
fine. All the time I was using the same three 16lf819's, and my "clean"
ones that I could reproduce the problem with too were all from the same
rail.

Embedded programming is downright wacky!

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGbr9/3bMhDbI9xWQRAhXnAJsHZ4VfM7f6uhlVEX10MgfN5bTdcQCeIU2X
ONZulV9nocMffezKudAZjzc=
=jBtE
-----END PGP SIGNATURE-----

2007\06\12@122938 by Jan-Erik Soderholm

face picon face
B.t.w, are you using "internal-MCLR" ?
Or how can the application interfere with the
programming ? Normaly (with "normal" internal MCLR)
the processor is held in reset-state until
Vpp is applied, so the code never runs...

Jan-Erik.

Peter Todd wrote:
{Quote hidden}

2007\06\12@124347 by PicDude

flavicon
face
I've had this on the 16F819 with both the internal Osc and internal Mclr
selected.  I've been using an ICD2 lately programming directly from MPLAB and
it actually warns of this.


On Tuesday 12 June 2007 08:57, Peter Todd wrote:
{Quote hidden}

2007\06\12@131625 by Jan-Erik Soderholm

face picon face
Damn, that should have been
(with "normal" EXTERNAL MCLR)
of course !

My guess is that this can be seen if
using *internal* MCLR...

Sorry...
Jan-Erik.

Jan-Erik Soderholm wrote:
{Quote hidden}

2007\06\13@173415 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jun 12, 2007 at 06:29:33PM +0200, Jan-Erik Soderholm wrote:
> B.t.w, are you using "internal-MCLR" ?
> Or how can the application interfere with the
> programming ? Normaly (with "normal" internal MCLR)
> the processor is held in reset-state until
> Vpp is applied, so the code never runs...

You guessed it, MCLR is disabled, so the programmer can't put the device
into reset... You would have though 13.5V on the reset line would have
done the job, but I guess not.

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGcGLF3bMhDbI9xWQRAuIdAJ9tFo/CiaDezfQctUsDxM1odkN5YQCfQyaM
xBhvN+XFk9yXh25eRA2pR2c=
=4rEv
-----END PGP SIGNATURE-----

2007\06\14@040624 by wouter van ooijen

face picon face
> You would have though 13.5V on the
> reset line would have done the job, but I guess not.

guessing is for those who want to live in "interesting times", if you
want a 'dull" time you should read the documentation :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\06\14@042954 by Alan B. Pearce

face picon face
>> You would have though 13.5V on the
>> reset line would have done the job, but I guess not.
>
>guessing is for those who want to live in "interesting times",
>if you want a 'dull" time you should read the documentation :)

<VBG> I'll have a guess too, relating to Vpp before Vcc ...

2007\06\14@132653 by alan smith

picon face
I was using 818...close enuf to the 819 I suppose....two boards, same layout diff stuff options.  One board could program with the icd2, the other would not, only with the pickit2 (both would program with the pickit2) but the internal osc wasn't 8MHz, but 2MHz. It would sometimes program...sometimes fail...sometimes neither would program....grrrrrr...drove me nuts.  

 Think part of the problem was the portB ICD pins were tied wierd (resistor dividers, IR emmiters,etc) but since the client uses the pickit2 to program....it was ok.
 
PicDude <spam_OUTpicdude2TakeThisOuTspamavn-tech.com> wrote:
 I've had this on the 16F819 with both the internal Osc and internal Mclr
selected. I've been using an ICD2 lately programming directly from MPLAB and
it actually warns of this.


On Tuesday 12 June 2007 08:57, Peter Todd wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...