>Very simple:  Allow me to disable ICSP reads no matter what, and allow me
to
>disable internal reads of the flash memory, but allow internal flash to be
>re-written.  So simple, they've done it now with the 77A and 18F series.
>And left me holding the bag with the miserable 77 for at least the next
half
>of a year.
>
>Face it, I'm screwed.  Can't do a chip recall, it's far too
>expensive/inconvenient/ridiculous/pathetic.

Having followed your rant somewhat I suspect you are going about your design
philosophy and reprogramming the wrong way

First, I wonder how often you will really need to do an update in the field.
If you really expect to upgrade more than a couple of times, I suspect that
that design procedure/verification has some holes.

Second, if you see reprogramming as feature upgrading this is surely a
chargeable thing in which case you build in the cost of a chip, including
some sort of carrier PCB if necessary. This is not that hard to do, for a
DIL chip it may just mean having the chip in another socket. Been there done
that swapped out thousands of EPROM's this way when I was doing technical
support and had some ham fisted engineers in the field.

Third, if your product is such that it is worth reverse engineering, and you
are thinking of having it field upgradeable by a bootloader, the very first
upgrade will be reverse engineered no matter how encrypted the download code
is. You only have to look at the hackers involved in disabling/reverse
engineering PC based code using all sorts of protection schemes to realise
that nothing is unbreakable. This would apply even if you could get your
hands on an F877A.

Fourth, your comment about having a quarter of the code as bank/page
switching as you go in and out of the protected area of the chip suggests to
me that you need to rethink the design philosophy of the code. When RCA
brought out the COSMAC chip they had an interpreter system that they wrote
their editor in which had subroutines represented by tokens. It was very
efficient and as a scheme would suit your purpose well. Have the subroutines
in the protected area and the tokens in the unprotected area would make it
very hard to reverse engineer the product. You then only ever upgrade the
tokens using the bootloader. I do not know if any of the Basic products for
the PIC could be set up this way, but there is certainly the basics of an
interpreter available on the web.

I suspect that you have not really thought through the problems associated
with the access you make available by having the code available through
download. If it is really such a precious commodity the only way to make it
hard for a reverse engineering attempt is chip exchange.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads