|
--- In , "Hugh O'Keeffe" <hugh.okeeffe@a...> wrote: > 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. If I understand how this will work, field upgrades will be impossible? It seems very risky to me to blow away a working version of a program before loading new code into a system in the field. Even then this will require a user to know enough about the tools to upload the new software. I have not heard how this is done. Is there a serial port programming utility like OKI has in the Boot ROM? |
|
|
Code Protection
Started by ●February 19, 2004
Reply by ●February 22, 20042004-02-22
Reply by ●February 23, 20042004-02-23
|
Message
-----Original Message-----
From: James Dabbs [mailto:j...@tga.com] Sent: 21 February 2004 13:54 To: l...@yahoogroups.com Subject: Re: [lpc2000] Re: Code Protection
|
|
|
Reply by ●February 23, 20042004-02-23
|
Message
From: r...@yahoo.com [mailto:r...@yahoo.com] Sent: 22 February 2004 06:14 To: l...@yahoogroups.com Subject: [lpc2000] Re: Code Protection
|
Reply by ●February 23, 20042004-02-23
|
> I guess this kind of protection is quite useless, perhaphs this is > why Philips doen't disclosure the JTAG direct access to Flash > read/write routines, but it's pretty simple to disassemble IAP > bootloader (I've read somewhere on Russian ARM forum that there are > few peoples who are doing this) and to have direct access to Flash > through JTAG instead through IAP > I even read on the same Russian forum that one guy sucessfully > overwrote (by mistake) bootloader Flash when tried to write huge file > through the Philips ISP, thus made the chip absolutely useless > without the bootloader code inside. I had tried to overwrite the bootloader by programming a big file. Nothing happened. All I got was a warning from the Philips ISP tool about file being bigger than the Flash. I had experimented with the different file sizes but the bootloader was never overwritten. Can you please dig some more information from the Russian forum. I won't discount the code read protection feature just because of some rumors. I would like to get my hands dirty with a chip and do more expriments to assess how difficult/expensive it is to break the protection. Regards Tom |
Reply by ●February 25, 20042004-02-25
|
> 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. When performing a full chip erase, the location 0x1FC is erased so the read protection is no longer enabled. There is a boot loader in the device that will not be erased, so new firmware can be uploaded to the device. The boot loader is invoked by pulling P0.14 low. Also, IAP is not disabled when read protection is. Jim --- In , "Hugh O'Keeffe" <hugh.okeeffe@a...> wrote: > -----Original Message----- > From: James Dabbs [mailto:jdabbs@t...] > Sent: 21 February 2004 13:54 > To: > Subject: Re: [lpc2000] Re: Code Protection > > > > AFAIK, when read protection is enabled all JTAG access (to flash) is > > > blocked as well as Read/Write/Copy/Go "bootloader" commands. > > > Hugh @ http://www.ashling.com/support/lpc2100/ > > Once a part is code protected, can it be erased and reprogrammed? > > Yes. Hugh @ http://www.ashling.com/support/lpc2100/ > > <http://rd.yahoo.com/SIGcgsfrt5/M'4551.4550177.5761904.1261774/D= eg > roupweb/S06554205:HM/EXP77457033/A 19528/R=2/*http://ad.double cl > ick.net/jump/N3349.yahoo1/B1282054.27;abr=!ie4;abr=! ie5;sz00x250;code= > 18634;dcopt=rcl;ord77370633936391?> Click HereClick Here > > <http://us.adserver.yahoo.com/l? M'4551.4550177.5761904.1261774/D=egrou > pweb/S=:HM/A 19528/rand0213512 > _____ > > > . |
Reply by ●April 16, 20042004-04-16
|
Hello, Does anyone know if FLASH read protect( 0x1FC with value 0x87654321 ) really works? Is there a work arround it to get to memory? Thanks, Gus |
|
|
Reply by ●April 17, 20042004-04-17
|
Hi Gus, This is a very interesting article on reverse engineering: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ > -----Original Message----- > From: Gus [mailto:] > Sent: Friday, April 16, 2004 10:51 AM > To: > Subject: [lpc2000] Code protection > Hello, > > Does anyone know if FLASH read protect( 0x1FC with value > 0x87654321 ) really works? > > Is there a work arround it to get to memory? > > Thanks, > > Gus |
|
|
Reply by ●April 19, 20042004-04-19
|
Message
Hi
Gus,
Yes, it does
work, however, note the following:
It's only
supported on 64-pin/144-pin LPC2000 devices with a Boot Loader ID
>= 1.6 (you can check your device's ID using Ashlings FlashLPC
utility or the Philips FlashISP utility).
Code
read protection is enabled by programming the flash address location 0x1FC (User
flash sector 0) with value 0x87654321 (2271560481 Decimal). If Read Protection
is enabled then the device has to be fully erased (thus disabling Read
Protection) before it can be re-programmed. In addition, you will not be able to
"connect" to the device via JTAG, hence, erasing must be done using
FlashLPC/FlashISP.
|
Reply by ●May 4, 20042004-05-04
|
Hi folks... I'm coming from AVR land, (because of defective Atmel silicon and looking at these LPC parts), and see that writing 0x1fc with 0x87654321 (sector 0 ?) protects the flash from being read. I am curious if this is actually documented by Philips or somewhere else. I cannot seem to find any references to it except on forums etc... Thanks, bob |
|
|
Reply by ●May 4, 20042004-05-04
|
--- In , "bobtransformer" <bgudgel@e...> wrote: > > Hi folks... I'm coming from AVR land, (because of defective Atmel > silicon and looking at these LPC parts), and see that writing 0x1fc > with 0x87654321 (sector 0 ?) protects the flash from being read. > > I am curious if this is actually documented by Philips or somewhere > else. > > I cannot seem to find any references to it except on forums etc... > > Thanks, > bob We are also moving to the LPC parts because of problems with the avr. For my interest, was your problems with the avr corruption of flash code at boot up ?? |
|
|
