Post by thread:[PIC]: about the flash memory on the 16F877

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

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? You can't read or write code protected ROM from within the chip, or from a programmer or from ICSP. Ages ago there was some threads about having a special config bit that would allow the chip to rewrite itself underneath the code protection. ie. the ROM can't be accessed from outside the chip but it can be rewritten internally. That way a bootloader could use encrypted code to update itself. Not a reality though and I guess, unless you are confident that the protected code will not need replacing, then using a bootloader for upgrades is no option. -- Best regards Tony mICros http://www.bubblesoftonline.com spam_OUTsalesTakeThisOuTbubblesoftonline.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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: {Quote hidden}>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.

Hello Adam. Thanks for taking the time to write. We did design for the 77, we knew of its very poor (non-existent?) code protection of FLASH memory, but chose the part anyway, took a gamble that the 77A would be available by go time, but it's not. We never knew that even code protected flash was readable by internal reads, meaning that any amateur hacker could put on code to do a memory dump of the code protected area. That is the achilles heel we didn't know about. That seems quite ridiculous, and in fact, is. The 77A was due out long ago, and is quite far delayed into the future, so now we are stuck with a poorly designed part. To say it's not microchip's fault is quite remarkable, given that the ONLY part of the chip that's not a commodity is the ROM image, and they've seen to it that it's impossible to protect. Again, TOTALLY RIDICULOUS. Do you have any suggestions how to preserve the flashability of the part through our bootloader while still protecting the chip from code copying and downloading, etc? Thank for any insight you can provide, it is truly appreciated, from a coder in a jam!!! -----Original Message----- From: pic microcontroller discussion list [.....PICLISTKILLspam@spam@MITVMA.MIT.EDU]On Behalf Of M. Adam Davis Sent: Wednesday, July 18, 2001 1:50 AM To: PICLISTKILLspamMITVMA.MIT.EDU Subject: Re: [PIC]: about the flash memory on the 16F877 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Ron Anthony wrote: >Do you have any suggestions how to preserve the flashability of the part >through our bootloader while still protecting the chip from code copying and >downloading, etc? > Nope. I'd say you are in quite a pickle. You have a few options: 1) Give up on the idea of upgrading the part in the field/by the customer 2) Give up on the idea of having complete code protection 3) Redesign your project to work with a part that, in your estimation, is not 'broken' 4) Seperate the project into a) Important, copy protected and non-upgradable bits b) Less Important, non-protected, upgradeable bits and redesign the project to use two chips, one protected and one not 5) Be up front with the customer and tell them you gambled and lost, and that they'll have to distribute upgrade chips and tools until the better chip comes out 6) Give us more of an idea as to what your project/product is/does (in a broad sense) so we may be able to suggest a better workaround, or at least tell us why you must have both copy protection and field upgrade capability, so we can suggest a possible work around. >Thank for any insight you can provide, it is truly appreciated, from a coder >in a jam!!! > Glad to be of assistance - good luck! Sound like you've hit the immutable law of three - choose two: Upgradeable, Cheap, Protected. Hopefully a compromise or kluge can be found. -Adam -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Note that the "B" version of the 877 datasheet, which is likely what Ron designed form, does _not_ explain the 'errata' if you will re: code protect. I think this gives him a certain justification for his own actions and for his irritation with mChip. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: "Ron Anthony" <.....ronantKILLspam.....OPTONLINE.NET> To: <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU> Sent: Wednesday, July 18, 2001 12:29 AM Subject: Re: [PIC]: about the flash memory on the 16F877 > Hello Adam. Thanks for taking the time to write. We did design for the 77, > we knew of its very poor (non-existent?) code protection of FLASH memory, > but chose the part anyway, took a gamble that the 77A would be available by {Quote hidden}> go time, but it's not. We never knew that even code protected flash was > readable by internal reads, meaning that any amateur hacker could put on > code to do a memory dump of the code protected area. That is the achilles > heel we didn't know about. That seems quite ridiculous, and in fact, is. > > The 77A was due out long ago, and is quite far delayed into the future, so > now we are stuck with a poorly designed part. To say it's not microchip's > fault is quite remarkable, given that the ONLY part of the chip that's not a > commodity is the ROM image, and they've seen to it that it's impossible to > protect. Again, TOTALLY RIDICULOUS. > > Do you have any suggestions how to preserve the flashability of the part > through our bootloader while still protecting the chip from code copying and > downloading, etc? > > Thank for any insight you can provide, it is truly appreciated, from a coder > in a jam!!! > > {Original Message removed}

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_gandlerspam_OUTgetmai.com http://www.getmai.com {Original Message removed}