>
> >>
>    Byron (and others in this discussion), why is this an issue? Setting the
> code protect bit is kind of like pulling a pin on a hand grenade and letting
> go of the handle. Once you've done it, you're committed... I can't see any
> R&D-related purpose in setting the bit.

The bit gets set be accident while programming and suddenly a useful part
becomes useless.

All of this centers around the JW part. I understand that Microchip needs
to use the same die for JW and OTP parts. But slagging really expensive
(really really really expensive) JW parts without hope of recovery is
a bit much.

>Asking Microchip to allow erasure of
> the bit, or an alternative bit, in the "JW" parts, seems a bit ridiculous to
> me considering the chip process issues. Byron, this is not directed to you
> but the discussion in general.

I never asked for it. I was simply observing the conversation which indicated
that overexposing JW parts would eventually erase the CP bit. I find that
solution fine.

> <<
>
> One issue is that it's often desirable to allow a customer to field-test a
> product with what is almost certainly *NOT* going to be the final version.
> At present, there are three methods:
>
> [1] Lend them an OTP part and later scrap it.
> [2] Lend them a windowed part (protected) and later scrap it.
> [3] Lend them a windowed part (not protected) and hope they don't steal your
>     code.

[1] is acceptable for that activity as far as I'm concerned. My concern is
spending upwards of $20 for a JW part for personal development then
having it become useless due to accidental erasure. JW parts are strictly
for development, not production. They should have some way of being recovered
if the CP is set.

>
> I think many peopl here would like to have another alternative:
>
> [4] Lend them a windowed part (protected), and later erase and reprogram it
>     with another version.

That would be nice. But if money and customers are involved, I believe that
[1] is a perfectly acceptable solution.

BAJ