Lpc2000

Bob, are you having a bad day or is it a bad month? Hopefully it will 
improve. In the past you have been a helpful happy chap and a welcome 
contributor to this group.

I was going to reply to your initial remarks (ouch) but others answered 
up very well. Could you please explain to me why you are so insistent on 
shooting down this thread (or is it Jaya?). Do you think that we really 
want this group to become fragmented into specialist groups like "Code 
read protection in ARM devices"? I can only shake my head at the thought.

Posting information that could prove useful to somebody in the group 
should be encouraged. We all appreciate the discussions whether they are 
relevant to what we ourselves are doing at the time or not, or should we 
then just burn >99.9% of the books at the library because we think they 
are not relevant? If it's relevant to LPC2000 then this is where it belongs.

I treat Jaya's volunteered information as a "this is what I did" post of 
interest. It would be foolish to expect him to do something more or 
differently unless we were paying him.

Didn't he say he did this because his students were killing their 
USB-LPC boards. As far as I understand it, it was not a code security 
issue per se but rather a way of finding a way to make the boards 
"student proof" (good luck!).

*Peter*

lpc2100_fan wrote:
> Jaya,
>
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> Chapter B3 about synchronized clock
>
> Somebody at Philips went through some effort and wrote a very nize
> summary on Dec 22
>
> This should give you a good idea why the bootcode is not available in
> source code:
>
> ----  quote  -------
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
>
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash technologies
> without impacting the end user. Philips Bootloader may reside in ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
>
> ----  end quote  -------
>
> Flash blocks change in size and timing. Providing a software interface
> that you just need to call is much more user friendly than running
> into support and debug issues every time an "expert" changes the code
> to his/her liking generating undefined events in the flash programming
> sequence or timing. 
>
> It is fine that you disassembled the bootloader, nice exercise. Using
> a reengineered version of the bootloader / programming software can
> probably not increase the functionality but I can assure you it will
> increase the trouble you get yourself and your customers in.
>
> Overall, I do not understand you, if you think the CRP is not save,
> then look at other devices and try to find one that is good enough for
> your high standards. So far there have been 50++ messages but nobody
> said that they were able to break the mechanism.
>
> So, once you were able to set CRP in a device that actually can be
> secured, which are all device but the LPC2104/5/6 and enable JTAG
> without doing a chip erase I would be interested in your data. But
> only then!
>
> As a previous poster said, please feel free to set up a new Yahoo
> group "Code read protection in ARM devices" and the enthusiasts will
> follow you there.
>
> As long as you post your assumptions, non-applicable bootloaders ....
>
> Bob