Firstly, this has been hashed and rehashed on this list multiple times. Please check the archives. All your questions, and more, are answered there. As per page 46 of the 16F87x data sheet (DS30292C): You CANNOT write (Internally via program instructions, or externally via ICSP) to program memory that has been code protected, and you cannot write internally via program instructions to any program memory if the WRT bit is cleared in the config. The WRT bit does not affect ICSP reads or writes. The ICSP cannot read or write protected areas. NOTHING affects the ability of the chip to read its own memory. If you leave ANY part of the chip unprotected, code can be written to that space which will read out ALL the code on the chip if the chip executes instructions in that area. Code protection cannot be removed without a block erase of the entire chip. What this all boils down to is that you based your design on a product (77A) which was not available at the time you locked it into the project, and you are officially out of luck. This is NOT Microchip's 'fault', nor could one say that their code protect is 'bad'. If you've been in the industry for a long time you'll have realized that you do not lock your design into a part you do not have in hand. IIRC, there really was no good solution. As you indicated, for complete protection the chip is essentially an OTP part. There is no way to leave a part of the chip unprotected without the possibility of someone inserting code to read the unprotected part out, unless you can insure that code inside the unprotected area is never run, only read (as in data), but that defeates the purpose of updating or upgrading the program. If you hadn't already designed the hardware, I'd suggest you add a 12cxxx part to the project which contains critical pieces of code (ie, your most secret routines shouldn't need upgrading, should they?) and have it code protected. Using a simple encryption/decryption between the two chips you can leave the main chip open for upgrades and non-proprietary processing, while the 12Cxxx acts as a dongle, doing the important bits of work. Hopefully your product has a specific function which does not change over time. If it does, perhaps the fault lies not in the part, but in the design. But then, why do you really need the upgradeability? Assuming you aren't turning into a bad software engineer and are releasing shoddy work with planned upgrades to full functionality, I can think of few reasons to use upgradeable capabilities, and many of those can be overcome by good planning and design. As we move into parts with more than 8k of program space, this may be more of a concern as debugging larger programs becomes more difficult. By then, though, we'll have chips with much better code protection abilities. -Adam P.S. I'm sorry if I appear to be rude in any way. Sending 3 high priority messages to the list ranting about how badly a particular product is designed, placing blame/fault on a company that has done nothing wrong, coupled with it being too late for me to approach nearly anything rationally... well, it irritated me tonight. I do hope, however, that this information was useful (which it should be unless you were asking rhetorical questions ;-) It does, however, stimulate my mind into another thought... Hmmm... Ron Anthony wrote: >Hello All. I am currently struggling with how to deal with the ridiculously >bad code protect on the 16F877. I am hoping to learn a few things from >those who are actively working with the flash memory. > >Here is the primary question: > >If I code protect the upper half of the chip, that is, 50% of the flash >memory, will someone be able to use an ICSP to put in code on the open lower >half that can internally read the code protected space and dump the contents >out of a port? Because if they can, there is no sense code protecting that >half of the chip. If I code protect the 256 bytes, can they not read those >as well? From what I understand, internal flash reads work on code >protected memory. So it is very easy to set up a memory dump of the code >protected space. Is this correct? > >If that is the case, my only options are to code protect the entire chip >(which will prevent memory dumps, but turns the flash part into an OTP part) >or to leave the chip totally naked for downloading and reverse engineering >and copying, however, I'll be able to distribute flash updates. We can not >use ICSP in the field, as this would require distributing the rom image in >its naked entirety, which is not an option. Plus there are no facilities on >the PCB for enabling ICSP as we used all the pins and the circuit design is >done. > >My last option is to code protect the entire chip, and have no option for >flash updates in the field by bootloader, and then, when the 77A comes out >(never???) we can simply eat the cost and send out new 77A chips to >everyone, and let them throw away their code protected 77s, which would >basically be useless. There is a socket on the PCB but the tool to remove >the part (a spring loaded PLCC removal tool) costs as much as the chip. So >even a chip recall would not be worth the trouble, that is, to have everyone >mail back there 77 chips, then bulk erase, then resell as one-offs. It >would not be worth the trouble. And if you pop out the chip with a paper >clip, for example, you'd bend the pins quite a bit unless you get real >lucky. > >In the meantime, I am buying my 16F877 at 20 MHz in the PLCC package for a >very good price and soon will have thousands in stock. If someone needs >some 16F77-20/L with no lead time and a very good price, let me know. I can >sell you some of my stock, we've got a big pipeline streamed and coming in. > >At any rate, what are your thoughts on the flash memory and how to deal with >it? > >Thanks all, from Ron Anthony > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics > > > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.