It would be interesting to me to see you build a flash microcontroller with half
the features that Microchip has.  You seem to have a lot of animosity towards
Microchip for what you believe is a ridiculous design.  If you don't like it, go
with another chip!  Frankly, I haven't yet seen a flash microcontroller with
decent code protection that can write its own memory under code protection.

Microchip developed an OTP device with code protection, then replaced the PROM
with flash for these particular chips.  That was a great improvement, but you
can't really expect them to make more than a few changes per upgrade.  It takes
a lot of manpower, and the way the code protect has been developed I doubt it is
an easy change for them to make.

I'm sure they are completely aware that this FEATURE is desired very strongly by
a portion of their customer base.

As far as your particular situation, unless your product is selling for less
than $500  then your customers won't balk at a $5 S&H fee for an upgrade.  You
send them a new chip, they send you the old one and a check for $5.  You
reprogram the old one for the next customer.

Of course, with adequate testing you shouldn't have to update older products.
If they want the latest and greatest they won't mind paying for an upgrade.

If you REALLY have to have these features EXACTLY the way you want them, there
are other solutions (which have been suggested).

I don't mean to offend you, but your approach to this problem seems bass
ackward.  You are trying to make a circle fit into an oval hole.  The PIC is
obviously not the solution to your problem at this time.  And I would not bet on
what they say about changing it any time soon, even if they are making the
changes now, it's going to be at least a year before we see them in the product.

As far as my opinion on how it should be done when it happens, I think it would
be overkill to have 4 bits of code protection for each block (external read and
write, and internal read and write)

It should be completely adequate to have 2 bits, one for external read and write
without a bulk erase, and one for internal read and write.  However, I fully
believe that the internal commands should include the chip configuration area,
so the program can change its own fuses.  All of these changes leaves more
vulnerabilities in the code protect, though.  External cracking becomes easier
with each function you have.

-Adam

anonlistpost anonlistpost wrote:
> As we all know from
> this discussion, Microchip totally blew it, and it is not possible to flash
> update ROM while maintaining code protection.
>
> So we still remain at square one.
>
> And, a far a replacing chips, how'd you like to eat $5 per chip times
> several tens of thousands of installations evry time you want to change, oh,
> a single line of code.  Ridiculous.  And, to boot, having your customer open
> a circuit, and having the inconvenience of a physical swap.
>
> What the heck is this, an OTP part in a socket for poor man's
> "upgradbility", or is this a FLASH chip?????
>
> Come on Microchip, pick up the damn slack!!!!!
>
> Do they read this?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's