Searching \ for '16F84 In-Circuit Programming Help' 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: '16F84 In-Circuit Programming Help'.

Truncated match.
PICList Thread
'16F84 In-Circuit Programming Help'
1998\07\27@170844 by David Sorlien

picon face
I have a printer port PIC16C84 programmer that I built exactly according
to David Taits' schematic:
http://www.man.ac.uk/~mbhstdj/files/pp.gif

Using his PP software (rev 0.4), I have never had a problem programming
a 'C84 in circuit. Once, an assembly firm switched vendors and a batch
of 1200 surface mount 16C84's were programmed with the wrong OSC fuse
settings. The assembler neglected to inform me of the vendor change, but
did not hesitate to call when none of the boards worked. My 'PP'
programmer saved the day.

So... this same contract assy house decided to switch to 16F84's (yep
same board!). They have so far built about 1500 using F84's, of which
only 400 remain to be shipped. Luckily for them, there has been no
problems due to the chip change this time. My problem is my client
requested a minor (but important) code tweak. The client will not accept
the 400 boards as is. No sweat, I thought. I'd just whip out my trusty
'PP' programmer and save the day, again.

I downloaded rev 0.5 of David Taits' software which supports the F84.

Here's my problem. The 16F84's program just fine, but cannot be read by
the PP. I verified correct programming by desoldering the 'F84 and using
a PICStart Plus. I carefully checked the PP wiring, but it appears fine,
and the debug functions of the PP software work as expected. Not being
able to read the chip means no verify. The boards are to be retested,
but this test will not be able to tell the difference beteen the new and
old PIC code. I could devise a new test, but the difference is only
detectable after about 20 minutes of run time. Not an option.

Has any one else had difficulties reading a 16F84 using the PP
programmer? Not verifying the programming would feel like driving down a
freeway with my eyes closed. I don't want to take the chance.

Dave Sorlien

1998\07\27@190607 by James Cameron

picon face
David Sorlien wrote:
> Here's my problem. The 16F84's program just fine, but cannot be read by
> the PP. I verified correct programming by desoldering the 'F84 and
> using a PICStart Plus.

If it wasn't for your testing with the PICStart Plus I would have said
perhaps the 16F84 is different to the 16C84 in that the code protect
bits are inverted.

--
James Cameron                              (spam_OUTjames.cameronTakeThisOuTspamdigital.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\07\28@001620 by Jim Robertson

flavicon
face
At 08:54 28/07/98 +1000, you wrote:
>David Sorlien wrote:
>> Here's my problem. The 16F84's program just fine, but cannot be read by
>> the PP. I verified correct programming by desoldering the 'F84 and
>> using a PICStart Plus.
>
>If it wasn't for your testing with the PICStart Plus I would have said
>perhaps the 16F84 is different to the 16C84 in that the code protect
>bits are inverted.

How long is this sort of misinformation going to be circulated on the
piclist?
I believe this is about the forth time this has come up in the last two
weeks.

It is the PWRTE bit that is inverted not the code protect bits.

Jim Robertson.

>James Cameron                              (.....james.cameronKILLspamspam@spam@digital.com)
>Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800
>
--------------------------------------------------------
Jim Robertson
NEWFOUND ELECTRONICS
Email: newfoundspamKILLspampipeline.com.au
http://www.pipeline.com.au/users/newfound
--------------------------------------------------------

1998\07\28@020554 by NCS Products

flavicon
face
>Here's my problem. The 16F84's program just fine, but cannot be read by
>the PP. I verified correct programming by desoldering the 'F84 and using
>a PICStart Plus. I carefully checked the PP wiring, but it appears fine,
>and the debug functions of the PP software work as expected. Not being
>able to read the chip means no verify. The boards are to be retested,
>but this test will not be able to tell the difference beteen the new and
>old PIC code. I could devise a new test, but the difference is only
>detectable after about 20 minutes of run time. Not an option.

I don't know if this is helpful to you, but I've found, when
switching from C84 to F84, using Parallax Complier & Programmer which
know nothing of the F84:

C84 can be verified if programmed with code protect on.
F84 *cannot* be verified if programmed with code protect on.

What I've done is program & verify with code protect off, then program with
code protect on and assume it programmed correctly.

1998\07\28@030903 by paulb

flavicon
face
James Cameron wrote:

> If it wasn't for your testing with the PICStart Plus I would have said
> perhaps the 16F84 is different to the 16C84 in that the code protect
> bits are inverted.

 And everyone keeps getting this mixed up.  It is not the Code Protect,
but the Power Up Timer Enable bit that is inverted between C84 and F84.
One must tend to on principle ask: "Why?", but the fact is that for most
applications the difference will never be noticed.
--
 Cheers,
       Paul B.

1998\07\28@031448 by James Cameron

picon face
Jim Robertson wrote:
> How long is this sort of misinformation going to be circulated on the
> piclist?

For as long as people decide to answer from memory rather than check the
specifications of the chips.

I did say "perhaps," which indicates I didn't check the data sheet and
was operating from biological cache.

--
James Cameron                              (.....james.cameronKILLspamspam.....digital.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\07\28@062742 by Caisson

flavicon
face
> Van: Jim Robertson <EraseMEnewfoundspam_OUTspamTakeThisOuTPIPELINE.COM.AU>
> Aan: PICLISTspamspam_OUTMITVMA.MIT.EDU
> Onderwerp: Re: 16F84 In-Circuit Programming Help
> Datum: dinsdag 28 juli 1998 6:19

[Cut]

> How long is this sort of misinformation going to be circulated on the
> piclist?
> I believe this is about the forth time this has come up in the last two
> weeks.
>
> It is the PWRTE bit that is inverted not the code protect bits.

This is _correct_ .  What remains to be said is that the F84 has got _TWO
TYPES_ of Code-protection (according to my specs). _Program-memory_
protection at bits 4 thru 6 , 8 thru 13 (all One's or all Zero's) and the
_Data-memory_ protection at bit 7.

In short : Write the Code-protect bit (like in the C84) into bits 8 thru 13
of the F84.  (Don't forget the PWRTE bit though :-)

Greetz,
 Rudy Wieser

1998\07\28@070729 by David Tait

flavicon
picon face
Rudy Wieser wrote:

> This is _correct_ .  What remains to be said is that the F84 has got _TWO
> TYPES_ of Code-protection (according to my specs). _Program-memory_
> protection at bits 4 thru 6 , 8 thru 13 (all One's or all Zero's) and the
> _Data-memory_ protection at bit 7.

The programming specs (at least the PDF document 30262b.pdf) makes it
clear that the data memory protection bit (bit 7) is unique to the
PIC16CR83/84.  Is it wrong?

It should be pointed out that the code protection on the 16F84 is very
different to that on the 16C84 (quite apart from the differences in
the configuration word).  On the 16C84 the protected part could be
read back providing a scrambled version of the original program,
however, the 16F84 reads back as all zeros.  That means the old
practice, advocated by Microchip, of using a dump of a known good
protected part to verify the correct programming of further parts is
no longer valid.  Verification of a 16F84 which is to be protected
must take place before the configuration word is written (my own
software does this during the programming process).  Now Jim is back
on board the PICLIST I'm sure he will put me right if this isn't the
case!

David
--
http://www.man.ac.uk/~mbhstdj

1998\07\29@025137 by Caisson

flavicon
face
> Van: David Tait <@spam@mbhstdjKILLspamspamAFS.MCC.AC.UK>
> Aan: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
> Onderwerp: Re: 16F84 In-Circuit Programming Help
> Datum: dinsdag 28 juli 1998 13:05
>
> Rudy Wieser wrote:
>
> > This is _correct_ .  What remains to be said is that the F84 has got
_TWO
> > TYPES_ of Code-protection (according to my specs). _Program-memory_
> > protection at bits 4 thru 6 , 8 thru 13 (all One's or all Zero's) and
the
> > _Data-memory_ protection at bit 7.
>
> The programming specs (at least the PDF document 30262b.pdf) makes it
> clear that the data memory protection bit (bit 7) is unique to the
> PIC16CR83/84.  Is it wrong?

No it is not & you are right.  Looking again in my docs the page has got a
header stating explicitily "PIC16F8X" .  The table I took as belonging to
that PIC states that it belongs to the 16CR83 & 16CR84.  I was too hasty
:-(

The code-protection bit must still to be copied in bits 4 thru 13.  :-)

Greetz & thanks for the pointer,
  Rudy Wieser

1998\07\29@025719 by David Sorlien

picon face
Thanks for all the suggestions PICLISTers.

Today, I found the problem. Most pins on the '84 are used in my design, this
includes PB6 and PB7. I used PB6 to drive a shutdown pin on a peripheral IC,
and PB7 was used as a status input from the same IC. I did not include
isolation resistors to facilitate in-circuit programming. My bad.

Seems that the PP programmer I built was able to overcome the effects of extra
circuitry on PB6 and PB7 when reading a 'C84, but not an 'F84. Both would
program perfectly if the verify option was turned off. However the 'F84 read
out as a blank device (all 1's). Lifting the peripheral pin that was connected
to PB6 allowed the programmer to read an 'F84. Perhaps the 'F84 has different
drive capability on PB6 when in programming mode, compared to a 'C84?

In hindsight, I should have added resistors to isolate PB6 and PB7 to allow
in-circuit-programming when I designed the board. Would have saved me a few
hours of hair pulling, and I am follically challenged already. In the future I
will always add some isolation to the programming pins, the board cost will
increase by about 10 cents (a fraction of a penny for each resistor plus 5
cents per part surface mount placement). Even if the PIC is not EEPROM based,
it might just save the day if unprogrammed parts happen to be used by mistake.

I'd like to thank David Tait, not only for providing free schematics and
software for the PP programmer, but also for sending me private email with some
suggestions to try. Is there such a thing as a virtual standing ovation? The
guy sure deserves one.

Dave Sorlien

1998\07\29@055216 by Jim Robertson

flavicon
face
At 09:47 28/07/98 +0200, you wrote:
{Quote hidden}

No doubt this was just to amuse me!  I just about wet myself laughing with
the irony of it. :-)

What a pity David got in first.  I really could have had some fun.

Ah, that's made my week, Thanks!!


Jim

--------------------------------------------------------
Jim Robertson
NEWFOUND ELECTRONICS
Email: TakeThisOuTnewfoundEraseMEspamspam_OUTpipeline.com.au
http://www.pipeline.com.au/users/newfound
--------------------------------------------------------

1998\07\29@055218 by Jim Robertson

flavicon
face
At 12:05 28/07/98 +0100, you wrote:
>Rudy Wieser wrote:
>
>> This is _correct_ .  What remains to be said is that the F84 has got _TWO
>> TYPES_ of Code-protection (according to my specs). _Program-memory_
>> protection at bits 4 thru 6 , 8 thru 13 (all One's or all Zero's) and the
>> _Data-memory_ protection at bit 7.
>
>The programming specs (at least the PDF document 30262b.pdf) makes it
>clear that the data memory protection bit (bit 7) is unique to the
>PIC16CR83/84.  Is it wrong?

Snip..

>software does this during the programming process).  Now Jim is back
>on board the PICLIST I'm sure he will put me right if this isn't the
>case!

Who me? Did you mean me?

Oh David, why would you say such a thing?  I'm just a friendly, kind
piclister like everyone else. Now you've gone and hurt my feelings.

Jim

P.S. Yes, you were right I'm sorry to say, on all accounts...

>David
>--
>http://www.man.ac.uk/~mbhstdj
>
--------------------------------------------------------
Jim Robertson
NEWFOUND ELECTRONICS
Email: RemoveMEnewfoundspamTakeThisOuTpipeline.com.au
http://www.pipeline.com.au/users/newfound
--------------------------------------------------------

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