Searching \ for 'Re[2]: Aghhh Code Protection Bit Problem .... (fwd' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=aghhh+code+protection
Search entire site for: 'Aghhh Code Protection Bit Problem .... (fwd'.

Truncated match.
PICList Thread
'Re[2]: Aghhh Code Protection Bit Problem .... (fwd'
1997\02\12@164311 by Brian Boles

flavicon
face
    The things that we have done to the code protection are all towards
    the goal of having the most secure device possible.

    Unfortunately, there is no where near enough volume in windowed JW
    parts to justify doing seperate silicon for those.  So, the price for
    protection is the loss of an occasional JW device.

    Note: when programming be real careful when you select your device
    type (i.e. 64 or 64A)......

    Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Re: Aghhh Code Protection Bit Problem .... (fwd)
Author:  David Nicholls <spam_OUTdavidTakeThisOuTspamSKYNET.CSN.UL.IE> at Internet_Exchange
Date:    2/12/97 6:34 PM


On Thu, 13 Feb 1997, Mike wrote:

{Quote hidden}

Yeah I'd imagine so !

>
> Does this also apply to the flash parts - wouldn't it be more efficient
> that the code protection be via EPROM type bit anyway ?
>
> Are there any moves by microchip (hi guys) to change to EPROM bit ?
>
       I hate to say it but  I recon judging by previous discussions I
have heard that the move was actually in the other direction. I reckon
that it may have been due to a worry by microchip that one may be able to
selectively erase parts of the windowed chip using perhaps a fine laser
beam or something. And by doing so only wipe the CP bit.. I.e. exposing
the protected code..
       I am no expert on the subject so all I have just said is purely
hearsay. Please correct me if I'm wrong in those assumptions.
       However on the note of Microchip doing something about the problem
I would suggest and hope I'm taken seriously that a variant of the
windowed chip be produced that has no code protect bit.. Surely this
wouldn't be difficult (I realise Chip changes incur fabrication costs )
but I believe there would definately be a large market for such chips as
most developers have no need to code protect their windowed versions..
It's easier to lock them in your drawer ! Could anyone who agrees with
this suggestion please voice your support to confrim such a market.





> And in any case since I hear that all code protected PIC parts are just
> as easy to read as the code protected motorola parts - wouldn't it be
> logical that a code protect chip could be erased and reused ?
>

       Hmmmm, Are you sure on that one ? I'm sure microchip wouldn't be
impressed !

> Rgds
>
>
> Mike
>


                                       Dave.



http://www.csn.ul.ie/~david

1997\02\12@172438 by Norm Cramer

flavicon
face
At 02:41 PM 2/12/97 -0700, you wrote:
>     The things that we have done to the code protection are all towards
>     the goal of having the most secure device possible.

Definitly a good goal.

>
>     Unfortunately, there is no where near enough volume in windowed JW
>     parts to justify doing seperate silicon for those.  So, the price for
>     protection is the loss of an occasional JW device.

The method I sugested in a prior post (Adding a code protect disable bit)
would allow using the same die.

>
>     Note: when programming be real careful when you select your device
>     type (i.e. 64 or 64A)......

Everyone makes mistakes.  If samples were easier and faster to get for the
little guy, it might not be as big of a problem.  I continually worry about
inadvertently blowing the code protect fuze and wasting my hard earned
cash.  I agree that the code protect had to be fixed but there had to be a
better way.

Norm

1997\02\12@175129 by Eric Smith

flavicon
face
Brian Boles <.....bbolesKILLspamspam@spam@CCMAIL.MICROCHIP.COM> wrote:
> The things that we have done to the code protection are all towards
> the goal of having the most secure device possible.

That's good.

> Unfortunately, there is no where near enough volume in windowed JW
> parts to justify doing seperate silicon for those.

I think many of us would be upset if you *did* use different silicon; that
would mean that the behavior JW couldn't be counted on to be the same as
an OTP.

> So, the price for protection is the loss of an occasional JW device.

Occasional?  With the PICSTART 16C and PICSTART Plus I am seeing a
failure rate of nearly 1%.  I've already thrown away a dozen JW parts
that mysteriously became code-protected.  If this had happened to me with
a home-made programmer I would assume that the programmer was poorly
designed.  What should infer about the PICSTARTs?

Several people here have suggested changes that could be implemented in
future parts which would preserve the protection while eliminating the
risk of destroying JW parts.

Norm Cramer <cramerspamKILLspamDSEG.TI.COM> suggested that an additional EPROM cell
be used to disable programming the code protect.  This cell would be under the
metalization just like the code protect bit.  Then the first thing we would
do when we buy JW parts is prgram the code protect disable.  For security
reasons the part would be designed such that if somehow both the code
protect disable and the code protect bit were *both* programmed, the
code protect would take precedence.

Another way to do this would be to have a pad that could be bonded to either
VCC or GND, and in one position it would disable the programming of the code
protect bit.  The JW would be bonded one way, and OTPs the other.  Note that
if the code protect bit was already programmed, changing the bond wouldn't
have any effect, so this wouldn't compromise the security.

Cheers,
Eric

1997\02\13@130333 by myke predko

flavicon
face
Eric Smith wrote:

>Occasional?  With the PICSTART 16C and PICSTART Plus I am seeing a
>failure rate of nearly 1%.  I've already thrown away a dozen JW parts
>that mysteriously became code-protected.  If this had happened to me with
>a home-made programmer I would assume that the programmer was poorly
>designed.  What should infer about the PICSTARTs?

Eric,

How are you using the PSP?  I have been worried about this as well, but I
did discover something about MPLAB and PSP that really has made me sleep
better at night (I can't find anybody who has JW parts and the book deadline
is coming due...).

If in MPLAB, you enable the PSP *BEFORE* doing your assemble/compile, when
the assemble/compile is complete and you click on "OK", you'll see that the
PSP is updated with all the correct information (the window will flash for a
second or so).

So, if you make sure your __CONFIG Statement (in MPASM) is correct and
enable the PSP before assembling in MPLAB, you won't have to worry about
having to set the configuration bits manually and accidentally make a mistake.

This is something that I discovered by playing around with MPLAB with the
programmer enabled earlier this week (I noticed that you could do execute
everything on the window when the Programmer was enabled, but not when one
of the Programmer action windows was shown).  I could not find this
documented *anywhere* and nobody at Microchip seems to know about this
feature.

I've screwed up a number of programming cycles by hitting the wrong config
options, but with this feature you no longer have to worry about them.

myke

"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do" - Bruce Wayne

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