Lpc2000

Are there any surprises in store when I try to use my Eclipse->GNUArm 
tool chain on the LPC2294?

Anyone have any experience with the Sparkfun LPC2295 Header Board?

Is the external flash programmed via JTAG?

Thanks
Richard

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>
> Are there any surprises in store when I try to use my Eclipse-
>GNUArm 
> tool chain on the LPC2294?
> 
> Anyone have any experience with the Sparkfun LPC2295 Header Board?
> 
> Is the external flash programmed via JTAG?

Duh!  Of course not!  I had looked at the schematic and still had a 
brain fade.

> 
> Thanks
> Richard
>

Do any of the LPC series have FLASH security on par with PICs and AVRs?
Or can you always just put a JTAG unit on it and copy out the memory?

Thanks.

> Do any of the LPC series have FLASH security on par with PICs and AVRs?
> Or can you always just put a JTAG unit on it and copy out the memory?


User Manual excerpt:

Code Read Protection (CRP)
--------------------------
Code read protection is enabled by programming the flash address location
0x1FC (User flash sector 0) with value 0x8765 4321 (2271560481 Decimal).
Address 0x1FC is used to allow some room for the FIQ exception handler. When
the code read protection is enabled the JTAG debug port, external memory
boot and the following ISP commands are disabled:
. Read Memory
. Write to RAM
. Go
. Copy RAM to Flash
The ISP commands mentioned above terminate with return code
CODE_READ_PROTECTION_ENABLED. The ISP erase command only allows erasure
of all user sectors when the code read protection is enabled. This
limitation does not exist if the code read protection is not enabled. IAP
commands are not affected by the code read protection.

My understanding is that LPC series do not offer any code protection
like that in PICs or AVRs.  I know that for AVRs, you can preload the
boot sector, lock it down, and ship the part to customers.  Customers
 can load their code, run your code in boot sector, but still would
not be able to read any of your code.  There is no way to do this on
for LPC series.

Philips's idea of boot sector protection (from erasure) is hiding of
flash progamming algorithms and providing IAP code that in the boot
sector which will block attempts to erase or write to boot sector.

If you look at the boot loader code, say for LPC2104, upon reset,
memory location 0x3fff8000 is witten with the part ID.  I suspect if
you are using JTAG, this is what gets returned as the JTAG IDENT. If
your setup can proceed even when the IDENT command does not return the
expected value, I suspect nothing else will stop you from reading
contents of flash.

--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:

>
> Do any of the LPC series have FLASH security on par with PICs and AVRs?
> Or can you always just put a JTAG unit on it and copy out the memory?
> 
> Thanks.
>

Your understanding of the LPC2000 flash security is right for the
LPC2104/2105/2106 as they exist today but wrong for any other LPC2000
subfamily as all the 64-pin and 144 pin devices and also the new
LPC2101/02/03 have Flash Security.

As Joel already pointed out in the respective User Manuals you will
find a section about code security, you don't find it in the
LPC2104/5/6 as they do not have the code security YET. 

SUMMARY: All LPC2000 excep the 2104/5/6 offer Flash Security option.

Robert

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
>
> My understanding is that LPC series do not offer any code protection
> like that in PICs or AVRs.  I know that for AVRs, you can preload the
> boot sector, lock it down, and ship the part to customers.  Customers
>  can load their code, run your code in boot sector, but still would
> not be able to read any of your code.  There is no way to do this on
> for LPC series.
> 
> Philips's idea of boot sector protection (from erasure) is hiding of
> flash progamming algorithms and providing IAP code that in the boot
> sector which will block attempts to erase or write to boot sector.
> 
> If you look at the boot loader code, say for LPC2104, upon reset,
> memory location 0x3fff8000 is witten with the part ID.  I suspect if
> you are using JTAG, this is what gets returned as the JTAG IDENT. If
> your setup can proceed even when the IDENT command does not return the
> expected value, I suspect nothing else will stop you from reading
> contents of flash.
> 
> --- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> >
> > Do any of the LPC series have FLASH security on par with PICs and
AVRs?

> > Or can you always just put a JTAG unit on it and copy out the memory?
> > 
> > Thanks.
> >
>

Thanks Robert for the clarification.

In the AVR's we can ship the product to customers with our code in
boot sector, and allow them load their own application code using our
code while still securing our code in boot sector from read access.

Can this be done with the new LPC2101-4 or other LPC2000 series?

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:

>
> Your understanding of the LPC2000 flash security is right for the
> LPC2104/2105/2106 as they exist today but wrong for any other LPC2000
> subfamily as all the 64-pin and 144 pin devices and also the new
> LPC2101/02/03 have Flash Security.
> 
> As Joel already pointed out in the respective User Manuals you will
> find a section about code security, you don't find it in the
> LPC2104/5/6 as they do not have the code security YET. 
> 
> SUMMARY: All LPC2000 excep the 2104/5/6 offer Flash Security option.
> 
> Robert

Why is external memory boot is disabled when CRP is active.  Is this
because code in external memory can always read flash no matter what?

Does this mean that if you need CRP you cannot have external memory?

--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote:
> User Manual excerpt:
> 
> Code Read Protection (CRP)
> --------------------------
> Code read protection is enabled by programming the flash address
location
> 0x1FC (User flash sector 0) with value 0x8765 4321 (2271560481 Decimal).
> Address 0x1FC is used to allow some room for the FIQ exception
handler. When
> the code read protection is enabled the JTAG debug port, external memory
> boot and the following ISP commands are disabled:
> . Read Memory
> . Write to RAM
> . Go
> . Copy RAM to Flash
> The ISP commands mentioned above terminate with return code
> CODE_READ_PROTECTION_ENABLED. The ISP erase command only allows erasure
> of all user sectors when the code read protection is enabled. This
> limitation does not exist if the code read protection is not
enabled. IAP
> commands are not affected by the code read protection.
>

Hello Jayasooriah,

Code Read Protection (CRP) was implemented with intention to protect 
on-chip Flash content from preying eyes. 

In context of a system with external memory, this means that 
external memory components can be used, but in that case LPC2000 
with enabled CRP cannot boot from external memory.

Once LPC2000 starts executing user's code it does not care if the 
code is on or off chip, as long as fetched op-code is valid. If a 
LPC2000 device would have CRP enabled and booting process would 
direct code execution to an application in external memory, there 
would be no way to protect on-chip flash content from being read by 
such application.

However, having CRP enabled in a system with external memory and 
booting from on-chip flash is perfectly valid scenario. As long as 
LPC2000 is not fetching any executable code from external memory, 
CRP will accomplish what it is designed for. This is the case when 
external memory is used for data storage only.

All in all, the moment an off-chip located code is fetched, CRP's 
role is voided.

Regards,

Philips Apps Team



--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> Why is external memory boot is disabled when CRP is active.  Is 
this
> because code in external memory can always read flash no matter 
what?
> 
> Does this mean that if you need CRP you cannot have external 
memory?
> 
> --- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote:
> > User Manual excerpt:
> > 
> > Code Read Protection (CRP)
> > --------------------------
> > Code read protection is enabled by programming the flash address
> location
> > 0x1FC (User flash sector 0) with value 0x8765 4321 (2271560481 
Decimal).
> > Address 0x1FC is used to allow some room for the FIQ exception
> handler. When
> > the code read protection is enabled the JTAG debug port, 
external memory
> > boot and the following ISP commands are disabled:
> > . Read Memory
> > . Write to RAM
> > . Go
> > . Copy RAM to Flash
> > The ISP commands mentioned above terminate with return code
> > CODE_READ_PROTECTION_ENABLED. The ISP erase command only allows 
erasure
> > of all user sectors when the code read protection is enabled. 
This

> > limitation does not exist if the code read protection is not
> enabled. IAP
> > commands are not affected by the code read protection.
> >
>

Am I right in assuming LPC2000 CRP is a software fence implemented in
the supplied boot loader code?

In the case of AVR, CRP is implemented in hardware.  This means that
locked down code in flash can be executed but not read from flash by
preying eyes.  Thus we ship products with our code locked down in the
boot sector assured that our code is secure from preying eyes.

If JTAG is used to bring LPC2000 out of reset on power up (and thus
stop boot loader code from executing), will this also void CRP?

The LPC2000 series support Quick-Pulse programming.  Can this method
of parallel programming be used by preying eyes to read CRP'ed code?

--- In lpc2000@...m, "philips_apps" <philips_apps@y...> wrote:

>
> Hello Jayasooriah,
> 
> Code Read Protection (CRP) was implemented with intention to protect 
> on-chip Flash content from preying eyes. 
> 
> In context of a system with external memory, this means that 
> external memory components can be used, but in that case LPC2000 
> with enabled CRP cannot boot from external memory.
> 
> Once LPC2000 starts executing user's code it does not care if the 
> code is on or off chip, as long as fetched op-code is valid. If a 
> LPC2000 device would have CRP enabled and booting process would 
> direct code execution to an application in external memory, there 
> would be no way to protect on-chip flash content from being read by 
> such application.
> 
> However, having CRP enabled in a system with external memory and 
> booting from on-chip flash is perfectly valid scenario. As long as 
> LPC2000 is not fetching any executable code from external memory, 
> CRP will accomplish what it is designed for. This is the case when 
> external memory is used for data storage only.
> 
> All in all, the moment an off-chip located code is fetched, CRP's 
> role is voided.
> 
> Regards,
> 
> Philips Apps Team

The JTAG is disabled on reset and it is enabled by the bootloader code 
when CRP is not enabled. See previous discussions on this list about 
JTAG debugging from reset for more information.

Richard.


jayasooriah wrote:

> Am I right in assuming LPC2000 CRP is a software fence implemented in
> the supplied boot loader code?
>
> In the case of AVR, CRP is implemented in hardware.  This means that
> locked down code in flash can be executed but not read from flash by
> preying eyes.  Thus we ship products with our code locked down in the
> boot sector assured that our code is secure from preying eyes.
>
> If JTAG is used to bring LPC2000 out of reset on power up (and thus
> stop boot loader code from executing), will this also void CRP?
>
> The LPC2000 series support Quick-Pulse programming.  Can this method
> of parallel programming be used by preying eyes to read CRP'ed code?
>
> --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
> >
> > Hello Jayasooriah,
> >
> > Code Read Protection (CRP) was implemented with intention to protect
> > on-chip Flash content from preying eyes.
> >
> > In context of a system with external memory, this means that
> > external memory components can be used, but in that case LPC2000
> > with enabled CRP cannot boot from external memory.
> >
> > Once LPC2000 starts executing user's code it does not care if the
> > code is on or off chip, as long as fetched op-code is valid. If a
> > LPC2000 device would have CRP enabled and booting process would
> > direct code execution to an application in external memory, there
> > would be no way to protect on-chip flash content from being read by
> > such application.
> >
> > However, having CRP enabled in a system with external memory and
> > booting from on-chip flash is perfectly valid scenario. As long as
> > LPC2000 is not fetching any executable code from external memory,
> > CRP will accomplish what it is designed for. This is the case when
> > external memory is used for data storage only.
> >
> > All in all, the moment an off-chip located code is fetched, CRP's
> > role is voided.
> >
> > Regards,
> >
> > Philips Apps Team
>
>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Can Philips comment if Quick-Pulse parallel programming can void CRP?

I am advised parallel programming used to load on-chip flash from
scratch can also read on-chip flash.

You can find which list parts can be access this way by looking at
PP/ISP/IAP column for LPC2000 series here:

http://www.microem.ru/pages/ARM/files/Microcontrollers%20selection%20guide%2009_2005.pdf

Note that all parts without external memory interface can be be
parallel programmed.

Parts with external memory interface however do not support parallel
programming.  I am told this is because these devices can be forced to
boot via external memory (by twiddling pins during reset) and allow
external code to initialise on-chip flash from scratch.

I need the above clarified ASAP before I can advise clients that their
code on LPC part shipped to customers is really protected from preying
eyes.

Many thanks.

Jaya

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:

>
> The JTAG is disabled on reset and it is enabled by the bootloader code 
> when CRP is not enabled. See previous discussions on this list about 
> JTAG debugging from reset for more information.
> 
> Richard.
> 
> 
> jayasooriah wrote:
> 
> > Am I right in assuming LPC2000 CRP is a software fence implemented in
> > the supplied boot loader code?
> >
> > In the case of AVR, CRP is implemented in hardware.  This means that
> > locked down code in flash can be executed but not read from flash by
> > preying eyes.  Thus we ship products with our code locked down in the
> > boot sector assured that our code is secure from preying eyes.
> >
> > If JTAG is used to bring LPC2000 out of reset on power up (and thus
> > stop boot loader code from executing), will this also void CRP?
> >
> > The LPC2000 series support Quick-Pulse programming.  Can this method
> > of parallel programming be used by preying eyes to read CRP'ed code?

Yes Phillips, please comment.  Jaya, thanks for bringing this up.

Joel

> Can Philips comment if Quick-Pulse parallel programming can void CRP?
> 
> I am advised parallel programming used to load on-chip flash from
> scratch can also read on-chip flash.
> 
> You can find which list parts can be access this way by looking at
> PP/ISP/IAP column for LPC2000 series here:
> 
> http://www.microem.ru/pages/ARM/files/Microcontrollers%20selection%20guide
> %2009_2005.pdf
> 
> Note that all parts without external memory interface can be be
> parallel programmed.
> 
> Parts with external memory interface however do not support parallel
> programming.  I am told this is because these devices can be forced to
> boot via external memory (by twiddling pins during reset) and allow
> external code to initialise on-chip flash from scratch.
> 
> I need the above clarified ASAP before I can advise clients that their
> code on LPC part shipped to customers is really protected from preying
> eyes.

At 10:42 PM 12/18/05 +0000, jayasooriah wrote:
>Can Philips comment if Quick-Pulse parallel programming can void CRP?
>
>I am advised parallel programming used to load on-chip flash from
>scratch can also read on-chip flash.
>
>You can find which list parts can be access this way by looking at
>PP/ISP/IAP column for LPC2000 series here:
>
>http://www.microem.ru/pages/ARM/files/Microcontrollers%20selection%20guide%2009_2005.pdf
>
>Note that all parts without external memory interface can be be
>parallel programmed.

That's somewhat intriguing.  It's the first I've heard of any hint at all 
that the parts can be programmed via a parallel programming algorithm 
rather than only via JTAG and serial port.  In fact given what has been 
revealed of the internals I would have said it was unlikely to be 
possible.  Have you any Philips references?  I can find no mention on their 
web site, indeed the closest I could find was a table that indicated that 
parallel programming was not an option for any of the LPC family.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> At 10:42 PM 12/18/05 +0000, jayasooriah wrote:
> That's somewhat intriguing.  It's the first I've heard of any hint
at all 
> that the parts can be programmed via a parallel programming algorithm 
> rather than only via JTAG and serial port.  In fact given what has been 
> revealed of the internals I would have said it was unlikely to be 
> possible.  Have you any Philips references?  I can find no mention
on their 
> web site, indeed the closest I could find was a table that indicated
that 
> parallel programming was not an option for any of the LPC family.
> 
> Robert

The Product Overview Edition 08/2005 says otherwise.  It is claimed to
have been prepared by Philips Microcontroller Customer Technical
Support Group.

Though I cannot find any parallel programming information for LPC2105
in data sheet or user manual, Philips has confirmed to me (in email)
that these parts can be parallel programmed.

This prompted me to searched for parallel programming information for
LPC series and found the product overview chart.

I am not sure about others, but from what I learnt in the last couple
of weeks in relation to: a) on-chip flash programming algorithm; b)
parallel programming info; c) errata sheets for LPC2105; and d) source
for the supplied boot loader code, it is now pretty clear to me why
Philips has chosen to provide boot loader code so that they do not
*have* to release the kind of information I discovered.

However, the issue relating to code security is a pressing one and I
cannot continue working on prototype designes for clients unless I
know for sure that the embedded code is secure from preying eyes.

So far one customer has already asked for LPC2105 to be replaced with
equivalent OKI replacement because of problems flash programming and
boot loader requirements.

Jaya

At 02:48 AM 12/19/05 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> >
> > At 10:42 PM 12/18/05 +0000, jayasooriah wrote:
> > That's somewhat intriguing.  It's the first I've heard of any hint
>at all
> > that the parts can be programmed via a parallel programming algorithm
> > rather than only via JTAG and serial port.  In fact given what has been
> > revealed of the internals I would have said it was unlikely to be
> > possible.  Have you any Philips references?  I can find no mention
>on their
> > web site, indeed the closest I could find was a table that indicated
>that
> > parallel programming was not an option for any of the LPC family.
> >
> > Robert
>
>The Product Overview Edition 08/2005 says otherwise.  It is claimed to
>have been prepared by Philips Microcontroller Customer Technical
>Support Group.

I was hoping for something a little more substantive than the third party 
link to the site you already posted.

>Though I cannot find any parallel programming information for LPC2105
>in data sheet or user manual, Philips has confirmed to me (in email)
>that these parts can be parallel programmed.


Philips, you need to clarify this.  Can these parts be parallel programmed 
or not?  Is the literature on your site wrong or is the letter that was 
sent to Jaya wrong.  They cannot both be right.

>This prompted me to searched for parallel programming information for
>LPC series and found the product overview chart.
>
>I am not sure about others, but from what I learnt in the last couple
>of weeks in relation to: a) on-chip flash programming algorithm; b)
>parallel programming info; c) errata sheets for LPC2105; and d) source
>for the supplied boot loader code, it is now pretty clear to me why
>Philips has chosen to provide boot loader code so that they do not
>*have* to release the kind of information I discovered.

Well, don't just leave us hanging ;)

>However, the issue relating to code security is a pressing one and I
>cannot continue working on prototype designes for clients unless I
>know for sure that the embedded code is secure from preying eyes.

Well it certainly won't be in a 2105.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:

> I was hoping for something a little more substantive
> than the third party link to the site you already posted.

Google search on "Philips SP uC ProdOv" gives quite a few hits, and I
am quite sure they are from the same source in Philips.

> Philips, you need to clarify this.  Can these parts be
> parallel programmed or not?  Is the literature on your
> site wrong or is the letter that was sent to Jaya wrong.
> They cannot both be right.

I am as anxious as you are to clarification by Philips.

> >I am not sure about others, but from what I learnt in the
> >last couple of weeks in relation to: a) on-chip flash
> >programming algorithm; b) parallel programming info;
> >c) errata sheets for LPC2105; and d) source for the
> >supplied boot loader code, it is now pretty clear to
> >me why Philips has chosen to provide boot loader code
> >so that they do not *have* to release the kind of
> >information I discovered.
> 
> Well, don't just leave us hanging ;)

For example, from version 1.48 of boot loader for LPC2104/5/6, one
could derive code to erase entire on-chip flash as follows:

> // select all sectors
> FMDEV[7] = 0xff0000ff;
> FMDEV[6] = 4;
> fmDelay(90);
> FMDEV[6] = 0;

> // wipe marked sectors(s)
> FMDEV[10] = CCLK/200;
> FMDEV[11] = (400*CCLK)/2048 + 1;
> FM_DEV[6] = 2;
> fmDelay(CCLK/90 + (400*CCLK + 2048)/9);
> FM_DEV[6] = 0;

> // wait for completion ...
> while ((FMDEV[6] & 0x1f) != 0)
>     ;
> while ((FMDEV[36]) & 4) == 0)
>     ;

Accidentally trashing FM_DEV[6] can result in disaster!

FMDEV[10] and FMDEV[11] appear to hold on-chip charge pump parameters
for generating erase (and write) voltages.  It is possible trashing
these locations can fry the part for good.

Now do you see why Philips would withold release of such information? 

Jaya

Where this code came from ? Do you have the full source code for any of 
the LPC boot loaders ?
Thanks, Mauricio



jayasooriah wrote:
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> > I was hoping for something a little more substantive
> > than the third party link to the site you already posted.
>
> Google search on "Philips SP uC ProdOv" gives quite a few hits, and I
> am quite sure they are from the same source in Philips.
>
> > Philips, you need to clarify this.  Can these parts be
> > parallel programmed or not?  Is the literature on your
> > site wrong or is the letter that was sent to Jaya wrong.
> > They cannot both be right.
>
> I am as anxious as you are to clarification by Philips.
>
> > >I am not sure about others, but from what I learnt in the
> > >last couple of weeks in relation to: a) on-chip flash
> > >programming algorithm; b) parallel programming info;
> > >c) errata sheets for LPC2105; and d) source for the
> > >supplied boot loader code, it is now pretty clear to
> > >me why Philips has chosen to provide boot loader code
> > >so that they do not *have* to release the kind of
> > >information I discovered.
> >
> > Well, don't just leave us hanging ;)
>
> For example, from version 1.48 of boot loader for LPC2104/5/6, one
> could derive code to erase entire on-chip flash as follows:
>
> > // select all sectors
> > FMDEV[7] = 0xff0000ff;
> > FMDEV[6] = 4;
> > fmDelay(90);
> > FMDEV[6] = 0;
>
> > // wipe marked sectors(s)
> > FMDEV[10] = CCLK/200;
> > FMDEV[11] = (400*CCLK)/2048 + 1;
> > FM_DEV[6] = 2;
> > fmDelay(CCLK/90 + (400*CCLK + 2048)/9);
> > FM_DEV[6] = 0;
>
> > // wait for completion ...
> > while ((FMDEV[6] & 0x1f) != 0)
> >     ;
> > while ((FMDEV[36]) & 4) == 0)
> >     ;
>
> Accidentally trashing FM_DEV[6] can result in disaster!
>
> FMDEV[10] and FMDEV[11] appear to hold on-chip charge pump parameters
> for generating erase (and write) voltages.  It is possible trashing
> these locations can fry the part for good.
>
> Now do you see why Philips would withold release of such information?
>
> Jaya
>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, Mauricio Scaff <scaffm@g...> wrote:

> Where this code came from ? Do you have the full source code
> for any of the LPC boot loaders?

I reverse engineered the source code for V1.48 boot loader starting
with memory dump of contents of boot sector code in a LPC2105.

I documented of Philips startup code, its implementation of the first
three IAP calls and the resulting procedure tree.

I stopped when I had all I need to write my own boot loader that
replaces the monster provided by philips.

I can be bribed :)  Seriously, if there is enough interest, I am happy
to post my findings and solutions up as a tutorial on the web.

Jaya

Well, I'd love to use that information that you have collected to 
perharps make an open source bootloader for LPC devices.
I think the original one is good, but, there are several things that 
could be improved, like upload of code not plain (so you can distribute 
you update files to the end user), and, a simple timeout would be great 
(if for some reason you start the bootloader, your application is dead 
forever...).


jayasooriah wrote:
> --- In lpc2000@yahoogroups.com, Mauricio Scaff <scaffm@g...> wrote:
>
> > Where this code came from ? Do you have the full source code
> > for any of the LPC boot loaders?
>
> I reverse engineered the source code for V1.48 boot loader starting
> with memory dump of contents of boot sector code in a LPC2105.
>
> I documented of Philips startup code, its implementation of the first
> three IAP calls and the resulting procedure tree.
>
> I stopped when I had all I need to write my own boot loader that
> replaces the monster provided by philips.
>
> I can be bribed :)  Seriously, if there is enough interest, I am happy
> to post my findings and solutions up as a tutorial on the web.
>
> Jaya
>
>
>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

Jaya Hi,
I am definitely interested in such code. Please keep
me in mind if you make your code available.

Thanks,
David

--- jayasooriah <jayasooriah@...> wrote:

> --- In lpc2000@yahoogroups.com, Mauricio Scaff
> <scaffm@g...> wrote:
> 
> > Where this code came from ? Do you have the full
> source code
> > for any of the LPC boot loaders?
> 
> I reverse engineered the source code for V1.48 boot
> loader starting
> with memory dump of contents of boot sector code in
> a LPC2105.
> 
> I documented of Philips startup code, its
> implementation of the first
> three IAP calls and the resulting procedure tree.
> 
> I stopped when I had all I need to write my own boot
> loader that
> replaces the monster provided by philips.
> 
> I can be bribed :)  Seriously, if there is enough
> interest, I am happy
> to post my findings and solutions up as a tutorial
> on the web.
> 
> Jaya
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

At 11:36 AM 12/19/05 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> > I was hoping for something a little more substantive
> > than the third party link to the site you already posted.
>
>Google search on "Philips SP uC ProdOv" gives quite a few hits, and I
>am quite sure they are from the same source in Philips.

Maybe so, but since the info that is on Philips site is in direct 
contradiction....


> > Philips, you need to clarify this.  Can these parts be
> > parallel programmed or not?  Is the literature on your
> > site wrong or is the letter that was sent to Jaya wrong.
> > They cannot both be right.
>
>I am as anxious as you are to clarification by Philips.
>
> > >I am not sure about others, but from what I learnt in the
> > >last couple of weeks in relation to: a) on-chip flash
> > >programming algorithm; b) parallel programming info;
> > >c) errata sheets for LPC2105; and d) source for the
> > >supplied boot loader code, it is now pretty clear to
> > >me why Philips has chosen to provide boot loader code
> > >so that they do not *have* to release the kind of
> > >information I discovered.
> >
> > Well, don't just leave us hanging ;)
>
>For example, from version 1.48 of boot loader for LPC2104/5/6, one
>could derive code to erase entire on-chip flash as follows:

<snip>


>Now do you see why Philips would withold release of such information?

Umm, OK, I sort of see what you are getting at.  But my sympathies for 
someone reverse engineering the boot code and then damaging their chip is 
somewhat limited.  It's certainly no messier than I would have 
expected.  From your comments I thought maybe you had found something 
unexpected or strange.  It certainly doesn't strike me as a major flaw, or 
even a minor one come to that.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

At 11:58 PM 12/19/05 +0000, jayasooriah wrote:
>I stopped when I had all I need to write my own boot loader that
>replaces the monster provided by philips.

Monster? How so?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Dear Robert,

Referring to the boot loader supplied as monster is SPAM?  Really?

What I meant to say is that I do not like Philips boot loader because
it takes up 8K (too big for what it does) had an inconvenient method
for loading programs, so cumbersome that Philips had to provide boot
flash loading utility which in itself is too big for what it does.

The boot loader also trashes memory at locations I least expected.

I prefer my own loader (written in C, under 4K as 32-bit code, smaller
as 16-bit code), requires no more than Intel format hex files a simple
terminal emulator (Minicom, Hyperterm, etc) for downloading. You need
only copy and paste hex records onto the terminal emulator window to
download code into RAM (or FLASH) and run it.

Jaya

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> At 11:58 PM 12/19/05 +0000, jayasooriah wrote:
> >I stopped when I had all I need to write my own boot loader that
> >replaces the monster provided by philips.
> 
> Monster? How so?
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always
restrictions,   be 
> they legal, genetic, or physical.  If you don't believe me, try to
chew a 
> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/

I want it !!!!!! heeheheheh


jayasooriah wrote:
> Dear Robert,
>
> Referring to the boot loader supplied as monster is SPAM?  Really?
>
> What I meant to say is that I do not like Philips boot loader because
> it takes up 8K (too big for what it does) had an inconvenient method
> for loading programs, so cumbersome that Philips had to provide boot
> flash loading utility which in itself is too big for what it does.
>
> The boot loader also trashes memory at locations I least expected.
>
> I prefer my own loader (written in C, under 4K as 32-bit code, smaller
> as 16-bit code), requires no more than Intel format hex files a simple
> terminal emulator (Minicom, Hyperterm, etc) for downloading. You need
> only copy and paste hex records onto the terminal emulator window to
> download code into RAM (or FLASH) and run it.
>
> Jaya
>
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> >
> > At 11:58 PM 12/19/05 +0000, jayasooriah wrote:
> > >I stopped when I had all I need to write my own boot loader that
> > >replaces the monster provided by philips.
> >
> > Monster? How so?
> >
> > Robert
> >
> > " 'Freedom' has no meaning of itself.  There are always
> restrictions,   be
> > they legal, genetic, or physical.  If you don't believe me, try to
> chew a
> > radio signal. "  -- Kelvin Throop, III
> > http://www.aeolusdevelopment.com/
>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

At 06:22 AM 12/20/05 +0000, jayasooriah wrote:
>Referring to the boot loader supplied as monster is SPAM?  Really?

Blame my hosting provider, They've added some sort of filter recently and 
the false positive rate is unreasonably high.  I try to remove them from 
the subject line before posting.  Obviously I missed one.  Sigh.

>What I meant to say is that I do not like Philips boot loader because
>it takes up 8K (too big for what it does) had an inconvenient method
>for loading programs, so cumbersome that Philips had to provide boot
>flash loading utility which in itself is too big for what it does.

Gee, I found it one of the more convenient ones.  You should try the ST10 
loader sometime :)  I prefer a command line based utility myself, and since 
one exists I'm quite happy.  As for those that download Intel Hex files, 
they've given me more grief than the Philips loader ever has.  As far as 
using 8K, none of that block is available to me anyway so whether it's 8 
bytes or 8K I can't tell the difference so why should I care?

>The boot loader also trashes memory at locations I least expected.

Details?  I haven't run into this sort of behaviour so I'm kind of curious 
as to what you've seen.

>I prefer my own loader (written in C, under 4K as 32-bit code, smaller
>as 16-bit code), requires no more than Intel format hex files a simple
>terminal emulator (Minicom, Hyperterm, etc) for downloading. You need
>only copy and paste hex records onto the terminal emulator window to
>download code into RAM (or FLASH) and run it.

I don't like this sort of behaviour myself, but strokes for folks.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/