Lpc2000

Hee, just kidding...pls don't mind

May be lpc2100_fan is one of the Philips chip engineer...
and does not want us to know:
- How to enable the 4 CAN ports on a LPC2124...
- Or may be how to enable the USB on LPC2138...
- Or may be how to enable some 2x 64K sectors on LPC2114...

Also rumours of Philips is trying to sell away it's whole semicon
division  (?? don't know how true is that)  Potential buyers
are Infineon and ST-Micro, but will be mostly just buying
part of the semicon...

Pls don't try to kill me....

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@t...> wrote:
>
> 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
>