Hello Roman, about the 12C508 doing ICSP on the 77, well, the ICSP protocol is very well known and understood. A simple circut can patch the comms pins and receive your entire rom image BEFORE the code protect is turned on. So that's basically giving away the store. THanks for the try. In the end, I'm still screwed. My metphysically given facts: 1. The 77 is the only chip avaialable right now, and for the next half year 2. My code must be protected to the extent possible, at least from my own factory overseas 3. My code must be field upgradable by way of an encrypted bootloader 4. The kernel will run naked, but call all the code protected routines from upper memory 5. Any code protected routine is OPT, so to keep them upgradable, every major thread must be preceeded by first a jump into open space (flashable, non-code protected) so that if necessary, in the future, the thread can be expanded in open naked space, which then obsoletes the corresponding code in the code protected "OTP" flash area. With only approx. 2k available for flash updates outside the naked kernel, it won't take much to use it up. That's why so many jumps are necessary, so if a thread is obsoleted, only that part that needs updated can be "patched" in naked flash, thereore keeping the fixes very small Look guys, bottom line, I'm having a real hard time understanding why everyone is defending a multi-billion dollar behemoth, who not only was aware that their chip architecture was fundamentally flawed more than 24 months ago, but made a business deicision to delay the fix solely for dollars sake, paying no heed whatsoever to the fact that their very customers are put a severe risk of code copying. Quite frankly, they did not give a sh*!*t. That's the pisser right there. And as for the encrypted bootloader, let's just say it's going to be a real time, 10 minute long operation consisting of many tens of megabytes of data to flash that 2k. Can you say "finding a needle in a haystack?" I've got some beuatiful tricks up my sleeve that quite frankly, if someone spends the time to get at my flash loader, well guess what fellas -- THEY'VE EARNED IT, and would likely be among one or two people on the planet who could actually appreciate the genius of the code they cracked. Hell, I'd buy them a beer and talk shop. In fact, I'd probably hire them immediately. :) But in the end, none of this should have been necessary. I will be spending hundreds of thousands of dollars on the 77 before the 77A comes out, and by that time, the work is done in code, so the 77 will serve as well as the 77A at that time, becuase it would be too late to put the genie back in the bottle. So now I've got code to write, miserable code that it is, painful, cofusing, mind numbing code, so let's consider this thread officially slain. I'm totally screwed by Microchip. End of story. Ron -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Roman Black Sent: Thursday, July 26, 2001 4:37 AM To: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC]: FINAL WORD: A great solution for the PIC16F877 problems (code protect,bootloader) Ron Anthony wrote: > > The chip is 100% re-flashable after code protection only if you get your > hands on the chip again, or recall every unit from around the world to do in > house flash updates. The logistics of that are so overwhelmingly > prohibitive that it can't be done. Hmmm. > > You are presuming that I can get my hands on the chip again once it's in the > field. Let's assume that's possible. Do you think I am going to receive > envelopes mailed from around the world with chips inside, erase, reflash and > code protect, and then mail back out to everyone? > My > only solution to preserve in-the-field-flash-upgradability and lower-half > security is to go through the coding hell I'm going through as I write this. Hi Ron, i've been watching this thread and I dont like to sound mean, but "fix the solution, not the problem" to butcher a Japanese expression. There are a number of solutions, given that: * you want the customer to upgrade their own product * you must use a 16F877 * code must be protected How about adding a 80 cent 12C508 to your board, which programs your 16F877 with data from an external port (which you must already have). The user could download new firmware from you via the net, plug their PC into the product, the 12c508 de-crypts the firmware and programs the 16F877 in standard ICSP mode. Full security, solution fixed. This gives you the same functionality you are asking for now, at the expense of adding a tiny cheap PIC. Now before you say that the boards can't be modded to add the 12c508, you could put the 12c508 plus a few parts in a tiny potting box, as part of the programming lead that goes from the product to the the PC. Neat and cheap. I think you are just hung up on bootloading, and I don't know why. It's never been as good a programming option as a proper ICSP dump. :o) -Roman -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads