Searching \ for 'Re[2]: Aghhh Code Protection Bit Pro' 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 Pro'.

Truncated match.
PICList Thread
'Re[2]: Aghhh Code Protection Bit Pro'
1997\02\12@185622 by Miller, Steve

flavicon
face
Several good suggestions have been offered for this problem.  Here is my
two cents.  The cheapest thing to change is software.  I would interested
in a programming suite of tools geared specifically at the development
environment.  I would like programming software that does not allow the
protection bits to be set ever.  This development software would never
code protect a part.  During development we could use this safe version,
for customer prototypes and production we could use full featured
programming software.

Here is an opportunity for all the folks writing programmer software.
Make us a version that will never intentionally set the code protect
bits.  I would gladly pay the cost of a few JW packages just to be sure
that I did not choose the wrong option.  I know that programming errors
can occasionally inadvertantly code protect a part.  However,  if we can
eliminate operator error, I think we can save quite a lot of chips!


------ Steve

1997\02\12@232042 by John Payson

picon face
> Here is an opportunity for all the folks writing programmer software.
>  Make us a version that will never intentionally set the code protect
> bits.  I would gladly pay the cost of a few JW packages just to be sure
> that I did not choose the wrong option.  I know that programming errors
> can occasionally inadvertantly code protect a part.  However,  if we can
> eliminate operator error, I think we can save quite a lot of chips!

At work we use a BP Microsystems programmer.  While I'm sure BP has probably
come up with an improved version, and while I like the BP for programming other
parts [e.g. 87Cxx, 68HCxx, etc.] on the 16C622 it gives the best of all ima-
ginable worlds...

[1] If you define blank memory as $FF-filled, the programmer will complain
   that it can't program any PIC's, because the two high bits on the PIC
   will always read zero.  While it is nice that the programmer does not
   blithely ignore the two MSB's [in case you have byte swap problems] it
   would be nice if it could ignore them for the specific case of $FFFF.

[2] Because of [1], it is generally necessary to use $00 as the fill pattern.
   Guess what this translates to on the option fuses?

[3] Also because of [1], overburning parts [even if the option fuses were set
   properly in the hex file] is difficult.  If you have a programmer which
   can NOP-out programmed bytes, it's often possible to burn each chip a
   number of times without erasing (if you're writing 16C62x code that's less
   than 512 bytes, for example, it's often a simple matter to use each chip
   four times).  Note that when developing small programs on, e.g., the
   12C508 this ability may largely obviate the need for window parts on some
   projects [I once tested about 30 software versions on three 12C508's]
   Unfortunately, by filling unused areas with zero, the BP prevents these
   areas from being used for something useful.

[4] If the BP programs a 16C622 with the code protect bit set, it will fail
   the verify step.  As a result, if you wish to program production parts
   and have them code-protected, you must program them, then edit the fuse
   map, then "program" them again while hitting "I" to ignore the fact that
   the devices aren't blank the second time 'round.

[5] While the BP has an option to "just" set the code-protect bit on a 16C622,
   this option is in fact broken and will also zero out the rest of the con-
   fig word.  As a result, it will 99% of the time effectively destroy any
   16C622 which you try to protect unless you want LP mode, etc.

As a consequence of the above, I built my own programmer, which has been used
to program over 2,000 parts; it includes a low-voltage blank-check and verify
(adjustable via pot) and programs parts at about 5.2 volts.  I have had a few
slight problems; to wit:

[1] On four of 12C508's out of a batch of 2,000 the programmer was unable to
   program certain addresses.  The failures were always with locations that
   were multiples of 16 words apart, and on any chip all failures would be
   on the same bit [e.g. bit 4 of addresses $4E, $5E, $7E, and $9E might
   fail].  Note that I suspect that it may be that bit 4 of every $xE add-
   ress would have failed, except that many of them were supposed to have
   been left high.

   The odd thing about the failure mode on all four parts is that they would
   verify correctly at 5.2 volts but these bad bits would appear blank at
   4.4 volts.  This is the opposite of what I'd expect, since usually a low
   supply voltage will cause marginal bits to appear programmed even when
   they're almost blank.

[2] On my window 16C622's, it seems to take MUCH longer to erase the parts to
   the point that they'll blank check at 4.4 volts than to where they'll
   blank check at 5.2; erasing to pass 5.2 takes about 5 minutes, while I've
   had chips bake for an hour and still not pass at 4.4 [they show up with
   an image of the old code].  Is this normal?  I'd expect some difference,
   but that is rather a lot.

1997\02\13@094406 by David Nicholls

flavicon
face
On Wed, 12 Feb 1997, Miller, Steve wrote:

> Several good suggestions have been offered for this problem.  Here is my
> two cents.  The cheapest thing to change is software.  I would interested
> in a programming suite of tools geared specifically at the development
> environment.  I would like programming software that does not allow the
> protection bits to be set ever.  This development software would never
> code protect a part.  During development we could use this safe version,
> for customer prototypes and production we could use full featured
> programming software.
>
> Here is an opportunity for all the folks writing programmer software.
>  Make us a version that will never intentionally set the code protect
> bits.  I would gladly pay the cost of a few JW packages just to be sure
> that I did not choose the wrong option.  I know that programming errors
> can occasionally inadvertantly code protect a part.


       That brings me back to one of my original questions.

Can anyone explain the programming sequence of a PIC.

i.e. How much error checking is involved ?

Does the programmer send a special command to access the fuses (so a
programmer could ommit this command and hence prevent hardware errors
accidently setting code protect. ?

Basically Microchip have pretty much ruled out the possibility of a
hardware change so is there anything programmers can do WITH EXISTING
CHIPS to be as sure as possible that code protect doesn't get set.

I realise it isn't too difficult to disable the e.g. -c option on the
command line parser but are there any further steps one can take to stop
accidental hardware 1 -> 0 errors . I.E. never have the chip in a mode
where it could program the code protect bit by only a single bit error.


                               Anyone please ?


>  However,  if we can
> eliminate operator error, I think we can save quite a lot of chips!
>
>
>  ------ Steve
>

               I'm sure some of the shareware writers may have already
taken up this challenge and I reckon this sort of option will probably be
available soon.


                               David.


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

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