|
One of the big failings of the LPC series is its lack of protection for the code programmed into it. MSP430 has the jtag fuse that can be blown. I've seen rumors that there is something in the works for later this year, but that's doesn't help us now. Does anyone ave any suggestions for an ARM based, low power, large flash (128k minimum) with a decent pin count that has som kind of code protection for its flash? Thanks, Brian -- ----------------- Brian C. Lane (W7BCL) Programmer www.shinemicro.com RF, DSP & Microcontroller Design |
|
|
Code Protection
Started by ●February 19, 2004
Reply by ●February 19, 20042004-02-19
|
Maybe it's an OpenSource(OpenCode) chip :))))))) GNU and shit Thursday, February 19, 2004, 5:24:41 PM, si napisal: > One of the big failings of the LPC series is its lack of protection for > the code programmed into it. MSP430 has the jtag fuse that can be blown. > I've seen rumors that there is something in the works for later this > year, but that's doesn't help us now. > Does anyone ave any suggestions for an ARM based, low power, large flash > (128k minimum) with a decent pin count that has som kind of code > protection for its flash? > Thanks, > Brian |
Reply by ●February 19, 20042004-02-19
|
Message
AFAIK, this will be supported by
the LPC2000. I think next mask revisions will have this feature.
|
Reply by ●February 19, 20042004-02-19
|
Brian It's a bit of a kludge, but you could use an AT91FR40162/4042. They have a piggyback flash in the same package as the CPU and the address & data lines are brought out. However, the package is a BGA, and if you don't bring the signals (including some form of JTAG enable) out from under the package, the part would have to be removed to get access to the data. We put a cut jumper under the BGA to be able to create a DEBUG board w/ JTAG access. Production boards had it disabled. If you need REAL code security then this is probably not the approach you want. Regards -Bill Knight R O SoftWare On Thu, 19 Feb 2004 08:24:41 -0800, Brian C. Lane wrote: One of the big failings of the LPC series is its lack of protection for the code programmed into it. MSP430 has the jtag fuse that can be blown. I've seen rumors that there is something in the works for later this year, but that's doesn't help us now. Does anyone ave any suggestions for an ARM based, low power, large flash (128k minimum) with a decent pin count that has som kind of code protection for its flash? Thanks, Brian |
Reply by ●February 19, 20042004-02-19
|
Hi Brian, I'm of the same conviction wrt code protection. My FAE told me late last year that protected parts *supposedly* would be out middle 2004, I'm certainly waiting. I had been waiting for an ARM part that had reasonalbly low pin count, high amount of RAM, low power and at least 2 UARTS/SPI/PWM + decent timers. The LPC2100 seemed perfect, but the lack of code protection was a cold shower. What is the big deal for vendors ? I would have thought that code protection is paramount. Even the MSP430 is woeful wrt protection. The idea that you have to provide full JTAG access on production boards,only to destroy it, IMO is plain dumb. The nicest scheme I've seen is with Cygnal's C8051 parts. You can partially protect the Flash, and eg. leave the upper part accessible to an OEM so they can call your embedded libraries, but they CANNOT read/write the Flash that you specify as secure (you program in a threshold address, and below that address is protected). You erase the part and all the ones set the threshold back to Top Of Flash. Why can't we get that on MSP430/LPC2000 ??? B regards, Kris ----- Original Message ----- From: "Brian C. Lane" <> To: <> Sent: Friday, February 20, 2004 3:24 AM Subject: [lpc2000] Code Protection > One of the big failings of the LPC series is its lack of protection for > the code programmed into it. MSP430 has the jtag fuse that can be blown. > I've seen rumors that there is something in the works for later this > year, but that's doesn't help us now. > > Does anyone ave any suggestions for an ARM based, low power, large flash > (128k minimum) with a decent pin count that has som kind of code > protection for its flash? > > Thanks, > > Brian > > -- > ----------------- > Brian C. Lane (W7BCL) Programmer > www.shinemicro.com RF, DSP & Microcontroller Design > > -- ------ > Yahoo! Groups Links > > a.. To |
Reply by ●February 20, 20042004-02-20
|
>One of the big failings of the LPC series is its lack of protection >for the code programmed into it. indeed this restrain LPC2000 use so far only for LED blink projects :) nobody would consider to do something serious without copy protection anyway it's still great chip for beginners who want to learn ARM architecture there seems to be a bugs in the silicon too, but hopefully this all will be improved, LPC2000 is quite inmature chip after all >Does anyone ave any suggestions for an ARM based, low power, large >flash 128k minimum) with a decent pin count that has som kind of >code protection for its flash? I have my eye on OKI chips: http://www.open-research.org.uk/ARMuC/index.cgi?ML67Qxxxx according to this web price range is $6-$10 and: http://www2.okisemi.com/us/docs/MCUTables-9.html ML67Q5003 seems perfect replacement for LPC2000 with it's 512K Flash 32K RAM 60Mhz ADC, I2C, UARTs etc. Best regards Tsvetan --- PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb) Development boards for ARM, AVR, PIC, and MSP430 (http://www.olimex.com/dev) |
|
|
Reply by ●February 20, 20042004-02-20
|
Cutting JTAG pins of the chip if they are not used may be a temporary
solution ;-)
|
|
|
Reply by ●February 20, 20042004-02-20
|
----- Original Message ----- From: "gokbektas" <> To: <> Sent: Friday, February 20, 2004 7:02 AM Subject: [lpc2000] Re: Code Protection > Cutting JTAG pins of the chip if they are not used may be a temporary solution ;-) You just need to cut one of them, of course. 8-) Leon -- Leon Heller, G1HSM Email: My low-cost Philips LPC210x ARM development system: http://webspace.webring.com/people/jl/leon_heller//lpc2104.html |
Reply by ●February 20, 20042004-02-20
|
Message
64-pin/128-pin
LPC2000 devices with a Boot Loader ID >= 1.6 have flash Read Protection.
Ashling users can can check your device's ID using FlashLPC
(I think the Philips ISP programmer supports this as well).
Code
read protection is enabled by programming the flash address location 0x1FC (User
flash sector 0) with value 0x87654321. If Read Protection is
enabled then the device has to be fully erased (thus disabling Read Protection)
before it can be re-programmed. We're currently
adding support for this in our tools; further announcements shortly.
BTW, use this information
at your own risk. Philips Applications will be making "official" announcements
shortly.
HTH
Hugh @ http://www.ashling.com/support/lpc2000/
|
|
|
Reply by ●February 20, 20042004-02-20
|
> I have my eye on OKI chips: > http://www.open-research.org.uk/ARMuC/index.cgi?ML67Qxxxx > according to this web price range is $6-$10 and: > http://www2.okisemi.com/us/docs/MCUTables-9.html > ML67Q5003 seems perfect replacement for LPC2000 with it's 512K Flash > 32K RAM 60Mhz ADC, I2C, UARTs etc. Just to mention... ARM has "RVDK" toolchain that costs $6,000 and it can be used for LPC2k family. IAR toolchain for LPC2k (limited edition) costs approx. only half of RVDK price, which is much better offer if you ask me. On the other hand, OKI has special deal with ARM so you can get "RVDK for OKI" toolchain for only $2,000. Although "RVDK for OKI" is not compatible with other MCU's like LPC, having this for your OKI MCU is great thing. OKI is smarter than Philips, obviously. Microchip will introduce dsPIC family soon (Q2 2004). As soon as they do that I might return to Microchip since they offer free tools (IDE, assembler, linker, debugger, etc.) including free RTOS scheduler (just scheduler) from CMX and you can get C compiler for less than $300 from CCS. Data Sheets are very comprehensive and great number of very useful Application Notes exist. Also, there is great number of free DSP libraries from Microchip including digital filters and other cool stuff. This is probably the reason why I'm using Microchip MCU's for past 9 years. And finally, Microchip is working on its own speech recognition solution for dsPIC family. Very brave. Philips is complete disaster. Support from Philips is equal to zero. Even that ISP tool looks like kids wrote it. You are convicted to third party expensive tools if you want to do any real job other than flashing LED's on GPIO. GCC will generate up to XY% more code than IAR or ARM compilers so using GCC might be real pain in the _ss for more demanding applications. Not to mention lack of proper documentation. Migrating from Microchip to Philips is very painful, at least it is for me. When compared to Microchip, dealing with LPC2k is like doing time in jail. Maybe I'm just spoiled but dealing with 240x160x16shades-of-gray graphic LCD, RS485 network, speech recognition, IrDA, ultrasonic flow meter, PMR446 radio receiver and all of that in a single package powered by two NiMH AAA's with fast charger and fuel gauge gives me no time to deal with tools like GCC. I'm supposed to use tools, not to spend my life studding them. Someone said something about "code protection issue" on LPC2k!? So, if you can avoid LPC2k... Unfortunately, I can't :-)) Or maybe I can? I don't know until I receive reply from OKI about IAP feature. If it's possible to have IAP on OKI MCU's - "good night Philips" and "hello OKI". I'm even thinking about loosing firmware upgrade feature (through IrDA) on my design just to avoid LPC2k. On the other hand I have meeting with Microchip people, here in Serbia, on February 26th and if work on dsPIC is close to the end, Microchip is back in the game. If they manage somehow to apply NanoWatt technology to dsPIC family I think that there will be no doubt about proper selection of MCU for future projects. This is my personal opinion. I'm probably wrong about few things regarding LPC2k but most of this is unfortunately true. Such a shame for such a good product. Regards, Igor |
