Ok, I have the same exact concerns as Ron, but I plan to use the new PIC18Fxxx devices. I plan to call Microchip this week and find out if the 18F series chips will suffer from the same problems discussed in this thread. I think Ron has some very relevant points. I don't think it is asking too much to have the following properties in these new Flash PICS 1. Allow the engineer to disable the ability to read and write to/from program memory via the ICSP/ICD interface pins AND allow the engineer to disable in-circuit debugging via the ICSP/ICD interface. If the engineer wants to reprogram the chip via ICSP/ICD interface or use an ICD with the PIC, it should require a full erase first. An erase cycle that leaves no trace of the previous firmware build. 2. With ICSP/ICD interface reads and writes disabled (as mentioned in #1), your firmware should still have the ability to perform reads and writes to the internal program memory. This will still allow for firmware updates via an internal bootloader routine (excluding the memory locations of the bootloader). I don't think Ron is asking too much of Microchip. The above properties give us the best of all words: Protection from reverse engineering of code, but allowing internal firmware updates via a software bootloader, perhaps custom designed with some type of internal decryption algorythm for maxmium protection for publically available firmware upgrades. Kind of like a bootloader firewall for your PIC. Now the important question, will the A version of the PIC16F77 have the above properties? And more importantly for me and perhaps others, will the 18F series devices have these above properties. When I get an answer from Microchip, I will post what I am told. Thanks Neil Gandler Founder, CTO MAI Technology Inc. P.O. Box 64072 Sunnyvale, CA 94088-4072 Phone & Fax: 408-904-5089 e-mail: neil_gandler@getmai.com http://www.getmai.com ----- Original Message ----- From: "M. Adam Davis" To: Sent: Tuesday, July 17, 2001 10:49 PM Subject: Re: [PIC]: about the flash memory on the 16F877 > 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. > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.