--- 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:
>
> 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:
-----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:
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
Reply by eman...@hotmail.com●March 5, 20072007-03-05
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:
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!
