EmbeddedRelated.com
Forums

LPC2210 Boot-loader protocol

Started by eman...@hotmail.com March 5, 2007
Hello All,

I'm trying to write an "application loader application" for the ROMLESS LPC2210.
(PC program & Target code for burning the flash, executed from internal RAM).

My PC SW is stuck after the transmission of the first UU-encode line which is ignored by NXP's boot-loader.
The data exchange till that point is as following:

PC sends : '?'
BLOADER answers : 'Synchronized' + CHAR(13) + CHAR(10) ;
PC sends : 'Synchronized' + CHAR(13) + CHAR(10) ;
BLOADER answers : 'OK' + CHAR(13) + CHAR(10) ;

PC sends : '14745' + CHAR(13) + CHAR(10);
BLOADER answers : '14745' + CHAR(13) + CHAR(10)
+ 'OK' + CHAR(13) + CHAR(10) ;
PC sends : 'A 0' + CHAR(13) + CHAR(10);
BLOADER answers : 'A 0' + CHAR(13) + CHAR(10) + '0'
+ CHAR(13) + CHAR(10);
PC sends : 'U 23130' + CHAR(13) + CHAR(10);
BLOADER answers : '0' + CHAR(13) + CHAR(10) ;
PC sends : 'W 1073741824 24' + CHAR(13) + CHAR(10);
BLOADER answers : '0' + CHAR(13) + CHAR(10);
PC sends : 26 2F 22 3F 59 31 43 50 47 5E
34 38 5C 29 5F 45 26 2F 22 3F
59 30 60 60

BLOADER answers :

BLOADER doesnt answer at this stage. If I try to add a check sum it doesn't help.
If I sent a new 'W' (Write RAM) command it's ignored.
The PDF data sheet (page 262 of "LPC221/2220 User Manual Fev. 01 -12 October 2005" ) doesn't solve/relate these problems:

1 Are the UU-encode lines acknowledged by the BLOADER ?

2 What separates between two Uuencode lines, assuming that they length
can vary from 4 bytes to 65.(How the BLOADER knows that the PC sent 21
UU-lines of 65 byte or one UU-line of 1300 bytes if no or
between the lines?)

3 - The check sum isnt a part of the data and should be sent after the 20
UU-encode lines. So, should it be encoded as UU-encode too ?

4 It is declared that "When the data fits less than 20 UU-encode lines
then the cheek-sum should be of actual number of bytes sent" .
Doe's this mean that I can divide the hex file to its natural record
length packets(i.e. maximum 16 of data byes = 24 UU-encode bytes)
and send a check sum after each 24 bytes, Then issue a new 'W' (write
RAM command) for the next HEX record line?
(These practice could help during the development because no need to
handle non successive address).
5 Table 231 (still in page 262) is the "ISP Write to RAM" command
description". It ends with an example:

'Example "W 1073742336 4" '

I would like to see the continuation of the quoted example, i.e. the data
exchange following: "W 1073742336 4"", till a new 'W' command
is permitted!

Thanks all helpers
Emanuel

An Engineer's Guide to the LPC2100 Series

Hi,

The Philips documentation for this is incomplete.

I used code from another project and some time reverse-engineering the
Philips loader to understand it better.

You may be interested in an existing project that achieves what you are
trying to do.

See pyLPCTools at sourceforge.net
http://sourceforge.net/projects/pylpctools/

Regards,
jason.

-----Original Message-----
From: l... [mailto:l...]On Behalf
Of e...@hotmail.com
Sent: 05 March 2007 20:23
To: l...
Subject: [lpc2000] LPC2210 Boot-loader protocol
Hello All,

I'm trying to write an "application loader application" for the ROMLESS
LPC2210.
(PC program & Target code for burning the flash, executed from internal
RAM).

My PC SW is stuck after the transmission of the first UU-encode line which
is ignored by NXP's boot-loader.
The data exchange till that point is as following:

PC sends : '?'
BLOADER answers : 'Synchronized' + CHAR(13) + CHAR(10) ;
PC sends : 'Synchronized' + CHAR(13) + CHAR(10) ;
BLOADER answers : 'OK' + CHAR(13) + CHAR(10) ;

PC sends : '14745' + CHAR(13) + CHAR(10);
BLOADER answers : '14745' + CHAR(13) + CHAR(10)
+ 'OK' + CHAR(13) + CHAR(10) ;
PC sends : 'A 0' + CHAR(13) + CHAR(10);
BLOADER answers : 'A 0' + CHAR(13) + CHAR(10) + '0'
+ CHAR(13) + CHAR(10);
PC sends : 'U 23130' + CHAR(13) + CHAR(10);
BLOADER answers : '0' + CHAR(13) + CHAR(10) ;
PC sends : 'W 1073741824 24' + CHAR(13) + CHAR(10);
BLOADER answers : '0' + CHAR(13) + CHAR(10);
PC sends : 26 2F 22 3F 59 31 43 50 47 5E
34 38 5C 29 5F 45 26 2F 22 3F
59 30 60 60

BLOADER answers :

BLOADER doesnt answer at this stage. If I try to add a check sum it doesn't
help.
If I sent a new 'W' (Write RAM) command it's ignored.
The PDF data sheet (page 262 of "LPC221/2220 User Manual Fev. 01 -12
October 2005" ) doesn't solve/relate these problems:

1 Are the UU-encode lines acknowledged by the BLOADER ?

2 What separates between two Uuencode lines, assuming that they length
can vary from 4 bytes to 65.(How the BLOADER knows that the PC sent 21
UU-lines of 65 byte or one UU-line of 1300 bytes if no or
between the lines?)

3 - The check sum isnt a part of the data and should be sent after the 20
UU-encode lines. So, should it be encoded as UU-encode too ?

4 It is declared that "When the data fits less than 20 UU-encode lines
then the cheek-sum should be of actual number of bytes sent" .
Doe's this mean that I can divide the hex file to its natural record
length packets(i.e. maximum 16 of data byes = 24 UU-encode bytes)
and send a check sum after each 24 bytes, Then issue a new 'W' (write
RAM command) for the next HEX record line?
(These practice could help during the development because no need to
handle non successive address).
5 Table 231 (still in page 262) is the "ISP Write to RAM" command
description". It ends with an example:

'Example "W 1073742336 4" '

I would like to see the continuation of the quoted example, i.e. the data
exchange following: "W 1073742336 4"", till a new 'W' command
is permitted!

Thanks all helpers
Emanuel

Yahoo! Groups Links
Hi Emanual,

My response as interpolated:

--- In l..., emanuelbenavidor@... wrote:
>
> Hello All,
>
> I'm trying to write an "application loader application" for
> the ROMLESS LPC2210.
>...
> PC sends : 26 2F 22 3F 59 31 43 50 47 5E
> 34 38 5C 29 5F 45 26 2F 22 3F
> 59 30 60 60
>
> BLOADER answers :
>
> BLOADER doesn't answer at this stage.
> ...

You need to terminate each UU-Encoded line with an EOL -- CR, LF or
CR-LF sequence.

>
> 1 Are the UU-encode lines acknowledged by the BLOADER ?

No. You can enable echo (enabled by default) and use loop-back ack.

> 2 What separates between two Uuencode lines, assuming that they
length
> can vary from 4 bytes to 65.(How the BLOADER knows that the PC
sent 21
> UU-lines of 65 byte or one UU-line of 1300 bytes if no or

> between the lines?)

The EOL delimits records. However, you have to work around the poor
implementation in the NXP boot loader.

Normally, if the program is to allow CR, LF or CR-LF sequences, it
would accept either CR or LF, and then discard LF (or CR) if this was
immediately preceded by a CR (or LF).

However the NXP loader does not do this. Whenever it receives either
a CR or LF, it simply waits for *just over* one character interval,
and then discards *unconditionally* whatever it gets during this interval!

So if you use CR or LF as EOL, you must not transmit anything for at
least two character intervals following any CR or LF. If you are to
use CR LF sequence, then you must ensure that LF follows CR within one
character interval.

The above can be done you are using native serial ports and your host
computer is not busy, but it can be tricky if you are going through
USB VCP interface.

You may also want look at another UART problem I have documented here:

http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html

>
> 3 - The check sum isn't a part of the data and should be sent after
the 20
> UU-encode lines. So, should it be encoded as UU-encode too ?

No, format it as a decimal (yes DECIMAL!) number.

>
> 4 It is declared that "When the data fits less than 20 UU-encode
lines
> then the cheek-sum should be of actual number of bytes sent" .
> Doe's this mean that I can divide the hex file to its natural
record
> length packets(i.e. maximum 16 of data byes = 24 UU-encode
bytes)
> and send a check sum after each 24 bytes, Then issue a new 'W'
(write
> RAM command) for the next HEX record line?
> (These practice could help during the development because no
need to
> handle non successive address).

Yes you can do that, but that is not a nice thing to do!

>
> 5 Table 231 (still in page 262) is the "ISP Write to RAM" command
> description". It ends with an example:
>
> 'Example "W 1073742336 4" '
>
> I would like to see the continuation of the quoted example, i.e.
the data
> exchange following: "W 1073742336 4"", till a new 'W' command
> is permitted!

Sorry, I dont understand your question here.

>
> Thanks all helpers
> Emanuel

You can get some ideas about how to communicate with your LPC using
SILL that can be found here:

http://www.cse.unsw.edu.au/~jayas/esdk/sill.html

and enabling debug mode so that you can see the dialog.

Hope this helps.

Jaya