Jim Robertson wrote:
> >Brian Gregory wrote:
> >The devices WERE fine, and had programmed several times, up until
> >the code protect bits got set by whatever glitch.
>
> I do not have a ICD so I cannot give exact directions but...
>
> The ICD most certainly does have the ability to break the code protection
> of a 16F876, there is code in the firmware to do this.

OK. Then I'll have to look deeper.

I did find that the programming app note requires a -different-
set of commands to program the config register when trying to
unset the code protect bits. I haven't yet seen anyone post a URL
for a disassembly of the ICD firmware, so I can't easily look at
it to confirm that the correct commands are being used.

> I would expect that MPLAB would read the config word first and send
> commands to break the code protection if required. This is certainly
> how the MPLAB/PICSTART PLUS combo works.

Thank you for that confirmation for PICSTART, but has NO ONE of
the 1800 odd subscribers here erased the code protect bits with
the Microchip ICD?

> If this is not working the reason might have something to do with the
> LVE bit being set in the config word and RB3 being held high by the
> target system. If this is the case then you will not be able to write

Thought about that in the design phase. I have a pulldown on RB3
to ensure that it comes up low, until I initialize the pin.

> anything to the target pic because it enters a lock-up state if RB3 is
> high during power-up. A solution would be to isolate RB3 on power-up
Oh? So that would explain the R/C delay that PicNpoke's ROMzap
bootstrap has in his design.
Does the same thing happen if /MCLR is pulled to 12V at powerup?

I'm trying to use HV pgmg mode with Tony's ROMzap hardware/software
to try to fix this problem. No luck so far, but VCC & /MCLR are
pulled high simultaneously. I'll add a delay R/C to see if that
gets me in.


and
> try again.
>
> Another possibility is that the WRT bit is programmed and this will
WDT? The config reg reads it as off, and my other bits are set as
expected and AFAIK CP doesn't affect config reads.

prevent
> any new code being updated. The possible solution here is to enable all
Wouldn't WDT be overidden by being in programming mode? I could
find no references in the doc about this.

code
> protection fully ON and program the config word. Then turn all the code

Tried that too. No Joy. And yet the devices still work as expected
with the old code.

> protection options OFF and reprogram the target as required. This will force
> MPLAB to issue commands to break the code protection and erase the entire
> device. This proceedure works for the picstart plus in the case of the
> data memory protection being enabled. It may have some use here.

Thank you for the suggestions. I shall see what happens with a few
other permutations. I've gone through just about all of them.

> Regards,
>
> Jim Robertson
> NEWFOUND ELECTRONICS

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.