Searching \ for '[PIC] Code protection on f873a' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Code protection on f873a'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Code protection on f873a'
2009\05\02@095146 by John Coppens

flavicon
face
Hello people,

I'm trying to program the fuses on a 16f873a, and have them set in the
original .asm code. The code generates 0x3F71, which is correct
(unprotected Code). After programming, the value is read back as 0x1F71
though.

The programmer is a home-brew serial classic, but it has served
faithfully for many years, and I'm not ready to suspect the hardware.

After a 'chip erase', the value is read back as 0x3fff, which at least
confirms the hardware can read ok.

After programming, the program is correct (it runs correctly). The only
thing off is bit 13 of the config word. (And the code _is_ read back as
0's).

Is this a 'feature'? I couldn't find a reference in the docs.

John

2009\05\02@101807 by olin piclist

face picon face
John Coppens wrote:
> I'm trying to program the fuses on a 16f873a, and have them set in the
> original .asm code.

So let's see it.  This is the mostly likely place for a screwup.

> The code generates 0x3F71,

How do you know?  Did you look at the HEX file?

Without the source code and the HEX file you have given us very little to go
on other than your say-so, which is of course suspect since you're coming
here asking about a problem.

> The programmer is a home-brew serial classic, but it has served
> faithfully for many years, and I'm not ready to suspect the hardware.

But the software is a candidate.  If all the other locations were programmed
correctly then the hardware is probably working.  However, the config word
is programmed differently and probably has some special case in the
programming code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\02@110648 by John Coppens

flavicon
face
On Sat, 2 May 2009 10:18:59 -0400
spam_OUTolin_piclistTakeThisOuTspamembedinc.com (Olin Lathrop) wrote:

Hi Olin,

Thanks for the reply.

> > The code generates 0x3F71,
>
> How do you know?  Did you look at the HEX file?

I know it, because my programmer software shows the config word as read
from the hex file. BTW, the config line is:

       __config _BODEN_ON & _PWRTE_ON & _WDT_OFF & _XT_OSC & _LVP_OFF

> > The programmer is a home-brew serial classic, but it has served
> > faithfully for many years, and I'm not ready to suspect the hardware.
>
> But the software is a candidate.  If all the other locations were
> programmed correctly then the hardware is probably working.  However,
> the config word is programmed differently and probably has some special
> case in the programming code.

Yes, I wrote the programmer code too. But it had worked with
same-algorithm pics before.

Anyway, it seems the culprit was the f873a. Today I got hold of
another one, and everything works fine - the config word is read back
correctly, and code protection is off, as it should be.

I reprogrammed the original f873a, and the error repeated. So I think I
can safely say the problem is in the chip!

Thanks for replying promptly.

John

2009\05\02@120012 by PPA

flavicon
face

Hi,


John Coppens wrote:
>
> I'm trying to program the fuses on a 16f873a, and have them set in the
> original .asm code. The code generates 0x3F71, which is correct
> (unprotected Code). After programming, the value is read back as 0x1F71
> though.
>
Since bit 13 should be duplicated in bit 5, you should have read 0x1F51.
If some special software does something wrong, code protection should be
off:
Datasheet says:
"All of the CP1:CP0 pairs have to be given the same value to enable the code
protection scheme"
So it seems that the device has a real problem (if 0x1F71 is really what is
in the chip)...
Note: the only way to restore CP bits is to do a full erase, OK. Are you
sure that the 0x3FFF is really read back from the device and not a default
display of the software after the bulk erase function?

-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/Code-protection-on-f873a-tp23346413p23347502.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\05\02@122622 by Jan-Erik Soderholm

face picon face
John Coppens wrote:

> BTW, the config line is:
>
>         __config _BODEN_ON & _PWRTE_ON & _WDT_OFF & _XT_OSC & _LVP_OFF
>

Where are the CP-settings ?
I'm missig one of the _CP_... constants.

Jan-Erik.

2009\05\02@171415 by John Coppens

flavicon
face
On Sat, 02 May 2009 18:26:20 +0200
Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:

> >         __config _BODEN_ON & _PWRTE_ON & _WDT_OFF & _XT_OSC & _LVP_OFF
> >
>
> Where are the CP-settings ?
> I'm missig one of the _CP_... constants.

I could have added them, but in this case they don't have any effect.
__config starts out with all 1s (0x3fff), and the above flags set bits to
0. In the particular case of the f873a (and a few others) leaving the bit
high (bit 13 in this case) leaves the device unprotected, which is what I
wanted.

John

2009\05\02@172043 by John Coppens

flavicon
face
On Sat, 2 May 2009 09:00:05 -0700 (PDT)
PPA <philippe.paternottespamKILLspampmpcomp.fr> wrote:

> John Coppens wrote:
> >
> > I'm trying to program the fuses on a 16f873a, and have them set in the
> > original .asm code. The code generates 0x3F71, which is correct
> > (unprotected Code). After programming, the value is read back as
> > 0x1F71 though.
> >
> Since bit 13 should be duplicated in bit 5, you should have read 0x1F51.
> If some special software does something wrong, code protection should be
> off:
> Datasheet says:
> "All of the CP1:CP0 pairs have to be given the same value to enable the
> code protection scheme"
> So it seems that the device has a real problem (if 0x1F71 is really
> what is in the chip)...
> Note: the only way to restore CP bits is to do a full erase, OK. Are you
> sure that the 0x3FFF is really read back from the device and not a
> default display of the software after the bulk erase function?

Hi Philippe,

Thanks for the hint, but the f873a has only one Code protect bit. Bit 5
is unused. This processor has only two possibilities - protect all or not.
I believe you may be confused with the f873, which does have two pairs of
code protect bits.

Granted that the protection scheme is somewhat complicated as it is
different for many processors!

John

2009\05\02@180041 by Jan-Erik Soderholm

face picon face
John Coppens wrote:
> On Sat, 02 May 2009 18:26:20 +0200
> Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam.....telia.com> wrote:
>
>>>         __config _BODEN_ON & _PWRTE_ON & _WDT_OFF & _XT_OSC & _LVP_OFF
>>>
>> Where are the CP-settings ?
>> I'm missig one of the _CP_... constants.
>
> I could have added them, but in this case they don't have any effect.

They absolutely, certenly have !

The constant that is missing is _CP_OFF (and _CPD_OFF, I guess).

And they whould have had the obvious effect of not having
this dumb conversation just because someone was lazy while
writing his code...

The point in having them there is to show that "Yes, I *have*
thought about them also, I've not forgoten about them...".

So you not only *could* have added them, you actualy *should* have
added them.


> __config starts out with all 1s (0x3fff), and the above flags set bits to
> 0. In the particular case of the f873a (and a few others) leaving the bit
> high (bit 13 in this case) leaves the device unprotected, which is what I
> wanted.

Irrelevant.
One should not need to know those details to read the code.

Best Regards,
Jan-Erik.



>
> John

2009\05\02@210450 by John Coppens

flavicon
face
On Sun, 03 May 2009 00:00:39 +0200
Jan-Erik Soderholm <EraseMEjan-erik.soderholmspam_OUTspamTakeThisOuTtelia.com> wrote:

> > I could have added them, but in this case they don't have any effect.
>
> They absolutely, certenly have !
>
> The constant that is missing is _CP_OFF (and _CPD_OFF, I guess).
>
> And they whould have had the obvious effect of not having
> this dumb conversation just because someone was lazy while
> writing his code...
>
> The point in having them there is to show that "Yes, I *have*
> thought about them also, I've not forgoten about them...".
>
> So you not only *could* have added them, you actualy *should* have
> added them.

This is one of the reasons I am afraid of asking questions on the PIC
list. I had a hardware problem, and now I'm getting a lecture on
programming. I am not a professional programmer. I haven't seen any
document/tutorial or even suggestions that all options should be
included. To be sure, on the comment lines before the actual __config, I
didn't include those in the mail, the configuration is documented, and
stated to be not code-protected.

Thanks,
John.

PS: BTW, certenly should be written as certainly, forgoten should be
forgotten, and actualy should be actually.

2009\05\03@101345 by olin piclist

face picon face
John Coppens wrote:
> This is one of the reasons I am afraid of asking questions on the PIC
> list. I had a hardware problem, and now I'm getting a lecture on
> programming.  I am not a professional programmer.

So getting a lecture on programming shouldn't bother you and is apparently
necessary.  There is a lot of bad software in the world, and poor
documentation is by far the biggest problem.  It needs to be pointed out
whenever it occurs, not just for the author but also for all the wannabes
listening in.

None of this should be reason to be afraid to post to the PIClist.  Since
1500 people or so will read a post, there's a real good chance at least one
of them will call you on it if you make a mistake.  That's the way the
PIClist, the internet, and life in general work.  Grow up and get over it.
It's nothing to be upset about.  If you truly didn't realize it was a
mistake, then you've learned something.  If you were sloppy, then hopefully
you will be suitably embarrassed to not do it again or go away if you can't
stop doing it again.  If you think you were right, then you can say so and
explain why.

In this case I agree with Dave.  This falls under the general philosophy any
programmer should follow, which is that it's not just about telling the
computer what to do, but also about telling others what you're trying to get
the computer to do and why.

> I haven't seen any
> document/tutorial or even suggestions that all options should be
> included.

You probably won't.  It's just common sense to not only document the
switches taken but also the available choices.

> To be sure, on the comment lines before the actual
> __config, I didn't include those in the mail, the configuration is
> documented, and stated to be not code-protected.

Documenting the config bits is a bit of a problem with MPASM.  I don't like
the mnemonics in the include file because they are cryptic.  That wouldn't
be so bad if MPLAB allowed comments on continued lines, but at least back
when I looked at this issue it didn't.  That means you can't put each switch
on its own line with a end of line comment explaining what it does.  Even
then, you can't trust this method to show the choice left to default.

I use a different scheme that I know some here won't like (and some may say
so, but that doesn't mean I'm going to run away and hide or be afraid to
post here just because someone <gasp> disagrees with me).  I don't use the
mnemonics at all but instead document every bit of the bit pattern.  For
example, here is a 16F876 config:

 __config b'11111101110010'
         ;  11------11----  code protection disabled
         ;  --1-----------  no in circuit dbg, RB6,RB7 general I/O
         ;  ---X----------  unused
         ;  ----1---------  flash memory is writeable by program
         ;  -----1--------  EEPROM read protection disabled
         ;  ------0-------  low volt in circ prog off, RB3 general I/O
         ;  -------1------  brown out reset enabled
         ;  ----------0---  power up timer enabled
         ;  -----------0--  watchdog timer disabled
         ;  ------------10  high speed oscillator mode


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\03@122810 by John Coppens

flavicon
face
On Sun, 3 May 2009 10:14:40 -0400
olin_piclistspamspam_OUTembedinc.com (Olin Lathrop) wrote:

>   __config b'11111101110010'
>           ;  11------11----  code protection disabled
>           ;  --1-----------  no in circuit dbg, RB6,RB7 general I/O
>           ;  ---X----------  unused
>           ;  ----1---------  flash memory is writeable by program

Not that different from what I use:

               lcdout_byte     b'00001100'     ; 00001D-- : 1=display on
                                               ; 00001-C- : 0=cursor off
                                               ; 00001--B : 0=blink off

And the macros make assembler look high-level (and autodocument code)...

Cheers,
John

2009\05\05@065551 by Alan B. Pearce

face picon face
>> The constant that is missing is _CP_OFF (and _CPD_OFF, I guess).
...
>> So you not only *could* have added them, you actualy *should*
>> have added them.
>
>This is one of the reasons I am afraid of asking questions on the
>PIC list. I had a hardware problem, and now I'm getting a lecture on
>programming.

Don't be scared of asking, grasshopper ... Do take Jan-Eriks comments in the
spirit they are meant - i.e. to be helpful. If you spend time looking at
which way the bits are in the config word, and leaving out options which you
think have the bits in the default state for what you want, you WILL later
run into trouble, as you go to port your code to another chip which has a
different arrangement of bit polarity. As Jan-Erik said, putting the
statement in shows you HAVE selected the correct option for what you want,
and not forgotten something.

Initially it wasn't evident that you did have a hardware problem. I
certainly do not know the default state of an the config word in an erased
873A, and what they represent as options.

>I am not a professional programmer. I haven't seen any
>document/tutorial or even suggestions that all options should be
>included. To be sure, on the comment lines before the actual __config,
>I didn't include those in the mail, the configuration is documented,
>and stated to be not code-protected.

But including all the options makes sure that everything is correctly
'documented' in the 'code' that matters, whatever your comments may say. Why
go digging in the documentation to find out what the bit states mean when by
putting the option in the code part of the file it makes sure your code
always assembles the same, even if MPLAB or the programmer makes different
assumptions about what should be the default. It has happened in the past
that MPLAB mucked some of these things up.

2009\05\05@185102 by Bob Axtell

face picon face
While it is true that PIClisters are intimidating, their advice can't
be matched ANYWHERE,
not even on the Microchip FORUM. So just ask, somebody will cough up
useable answer.

Not a day goes by that I fail to get one or more GOOD ideas from the list.

--Bob A

On Tue, May 5, 2009 at 3:56 AM, Alan B. Pearce <@spam@Alan.B.PearceKILLspamspamstfc.ac.uk> wrote:
{Quote hidden}

> -

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