'Code Protection w 16C84'
|I just bought a PicStart Plus and Myke Predko's book about programming PICs.
I read his warning about the code protection bit so I made sure I didn't set
it. I burned my first program into the 16C84 and then tried it on a proto
board. I put it back on the PicStart Plus programmer and read the program
and then wrote it again. When I read it however, I didn't notice that it
read the code protection bit as being "on". I was sure that it was off when
I read it the first time. I was using one of Myke's samples. It turns out
that I now have the code protection bit on and I can't erase the PIC. The
tech specs that were on the CD with the PicStart Plus give the following
blurb about turning the CodeProtection off.
4.1 Disabling Code-Protection
It is recommended that the following procedure be performed
before any other programming is attempted. It is also possible
to turn code protection off (code protect bit = 1) using this
procedure; however, all data within the program memory and the
data memory will be erased when this procedure is executed, and
thus, the security of the data or code is not compromised.
Procedure to disable code protect:
a) Execute load configuration (with a '1' in bit 4,code protect).
b) Increment to configuration word location (0x2007)
c) Execute command (000001)
d) Execute command (000111)
e) Execute 'Begin Programming' (001000)
f) Wait 10ms
g) Execute command (000001)
h) Execute command (000111)
I don't know how to do this.
Does anyone have a suggestion?
Have you tried to reprogram the PIC without regard to the Code Protection
Bit? I don't have a PicStart Plus near me right now to try this out on, but
I thought if you program a Flash/EEPROM device using PICStart Plus/MPLAB
that has been code protected, the software automatically runs through the
erase procedure before programming.
Anybody else know for sure? Maybe you can try it and let us know if it works.
What I do to always make sure that I don't screw up the Configuration bits
is to first enable the PICStart Plus and *then* assemble the source code
(which has a valid "__CONFIG" Statement). Once the assembly is complete,
you'll notice that the Configuration bits in the PICStart Plus window will
be at the correct states.
For whatever reason, when you first enable PICStart Plus with a project that
has been compiled, the correct code is loaded, but not the correct
Good luck and please let us know how you make out.
"I was well aware that the processes of puberty are often fatal to psychic
- Sir Arthur Conan Doyle
With new found confidence I tried reprogramming again today and it worked.
Last night however, it wouldn't - I always got an Error writing the
configuration bits. Maybe the trick was just to restart the programmer or
MPLAB or Windows 95 or ... . Anyhow, I'm glad that I don't have to drive
for 40 min to get another 16C84.
>Have you tried to reprogram the PIC without regard to the Code Protection
>Bit? I don't have a PicStart Plus near me right now to try this out on,
>I thought if you program a Flash/EEPROM device using PICStart Plus/MPLAB
>that has been code protected, the software automatically runs through the
>erase procedure before programming.
>Good luck and please let us know how you make out.
|Brian Schoenhofer wrote:
> With new found confidence I tried reprogramming again today and it
> Last night however, it wouldn't - I always got an Error writing the
> configuration bits. Maybe the trick was just to restart the
> programmer or
> MPLAB or Windows 95 or ... . Anyhow, I'm glad that I don't have to
> for 40 min to get another 16C84.
I've had a similar experience with 16C84s (I use Micromint PICStics w/
the MELabs programmer). I would notice after a series of program, "it
(the program) don't work", edit, recompile, program, etc. that after a
while the '84 would refuse to verify. I could take the faulty '84 that
had laid around for a few weeks and reprogram it and everything would be
fine. I had attributed this to being some weird quirk of the MELabs
programmer, so rigged up an adapter to program the PICStics from a
PICStart+. I would encounter the problem less often, but eventually I
would get an '84 that wouldn't verify. I have also wondered if this
wasn't due to an ESD problem - not gross arcing, but enough low level
static build up to cause a slow degenerating problem.
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...