Good idea Bob.
Would seperate write and read protect fuses solve the problem ? The only way to clear these bits
being to erase the device?

The only problem I can see with this is verifying flash writes, but this could be done by a return
value from the flash write hardware - i.e. there is hardware checking the write was ok.
(have to be careful here that a chunk of code can't do a hacked read by writing a byte and then not
waiting for the write to complete - or not charging up the flash circuit with the writes of 0x55 and
0xaa first - repeat up to 256 times per byte and you know what the byte is - it's the value that
appeared to program correctly)

If you don't have seperate controls for read and write then you can always download a 'rogue' new
program that just overwrites the first byte with a jump to a routine to read all of memory. Do this
twice and you can read all of the memory in a chip bar the first byte.

Personally I think I would just try and avoid having a flash updatable PIC with 'sensitive' code on
it. If you are letting the end user flash the new code on to the pic then they can always hack your
protection system (if you have one) and find out what the new code you are downloading is. If they
are having to return the device to you for you to update it or you are sending someone out in the
field to update it, then the cost of a socket and a few otp chips is going to be a lot less than the
cost of your employees time anyway.

Regards,
Simon

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