Application Note
Writing an embedded
application loader
First edition (January 2005)
Sony Ericsson Mobile Communications. publishes this manual without making
any warranty as to the content contained herein. Further Sony Ericsson Mobile
Communications. reserves the right to make modifications, additions and
deletions to this manual due to typographical errors, inaccurate information, or
improvements to programs and/or equipment at any time and without notice.
Such changes will, nevertheless be incorporated into new editions of this
manual.
All rights reserved.
© Sony Ericsson Mobile Communications., 2005
WRITING AN EMBEDDED APPLICATION LOADER
LZT 123 8094 P1A 3
Contents
1 Introduction ........................................................................................4
2 Overview .............................................................................................5
2.1 AT commands ...........................................................................................5
2.2 The first packet..........................................................................................5
2.3 Subsequent packets ..................................................................................6
2.3.1 Xmodem-CRC Protocol (CCITT) ...................................................6
2.4 SLP DLL tool .............................................................................................9
WRITING AN EMBEDDED APPLICATION LOADER
4
LZT 123 8094 R1A
1 Introduction
Under a number of circumstances either the M2Mpower
IDE of the loaders program is not appropriate for loading
an embedded application onto a GR or GT module. In this
case the developer needs to write a loader for themselves.
The integrators manual provides the integrator with some
information but not enough to complete development of
such a tool. This application note provides the rest of the
required information and explains some further tools that
SonyEricsson have developed to aid in the
implementation.
WRITING AN EMBEDDED APPLICATION LOADER
5
LZT 123 8094 R1A
2 Overview
To download a script to the module the file transfer needs
to follow certain procedures and formats. The following
sections describe these and enable the developer to write
their own loader which will work in conjunction with the
module.
2.1 AT commands
The download is initially started off using AT commands,
specifically they are AT*E2APD and AT*E2APC these are
described in full in the GR47 AT commands manual.
2.2 The first packet
The first packet is sent to the unit to give it some
information about the script that is about to be downloaded
this aids a more reliable download. It is downloaded in X
modem protocol as described in section 2.3.1.
The first packet consists of the following information about
the script.
1. Number of lines (first 2 bytes)
2. Number of constants (second 2 bytes)
3. Number of tokens (third 2 bytes)
4. Number of keywords (fourth 2 bytes)
5. Number of identifiers (fifth 2 bytes)
Note! These values are sent little-endian (low byte, high byte).
As per the description of the X modem packet any unused
bytes of the 128 byte word are packed out with FF’s and
the CRC checksum calculated as normal.
When downloading with the IDE it will calculate these
numbers and then create the packet itself. To have this
implemented in an application it needs to calculate these
figure from the script. These numbers should be
calculated using the tool described in section 2.4.
WRITING AN EMBEDDED APPLICATION LOADER
6
LZT 123 8094 R1A
2.3 Subsequent packets
The basic format of the packets are X modem protocol,
the script is downloaded in raw ASCII format with no
interpretation required. It is upto the user application to
remove any comments, redundant prtf statements, etc.
2.3.1 Xmodem-CRC Protocol (CCITT)
The Download of scripts with the AT*E2APD command
uses the Xmodem-CRC protocol.
The following terms are simply ASCII codes:
• SOH = chr(1) = CTRL-A = Start of header
• EOT = chr(4) = CTRL-D = End of Transmission
• ACK = chr(6) = CTRL-F = Positive
Acknowledgement
• NAK = chr(21) = CTRL-U = Negative
Acknowledgement
• CAN = chr(24) = CTRL-X = Cancel
In order to send the file, the application must first divide it
into 128 byte packets. Bytes 0-127 of the file make up the
first packet, bytes 128-255 make up the second packet,
etc.
The packet number sent is simply the number of the
packet (packet number starts at 0 at beginning of
transmission). If the packet number is greater than 255,
then subtract 256 repeatedly until the number is between
0 and 255. For example, if you were sending packet 731,
then you would send 731 - 256 - 256 = 219.
The 1's complement of a byte is simply 255 minus the
byte. For example, if you had to take the 1's complement
of 142, the answer would be 255 - 142 = 113.
2.3.1.1 Cyclic Redundancy Check
In X-Modem CRC, it is also referred to as CRC-16 since
there are 16 bits (1 word) at the end of the block that
contain the CRC. This 1 word (2 byte) CRC replaces the 1
byte checksum in X-Modem. In this implementation the
CCITT polynomial is used to generate the CRC - X16 +
X12 + X5 + 1.
CRC-16 guarantees detection of all single and double bit
errors, all errors with an odd number of bits and over
99.9969% of all burst errors.
WRITING AN EMBEDDED APPLICATION LOADER
7
LZT 123 8094 R1A
The easiest and fastest way to calculate the CRC is to use
a lookup table.
The first byte the downloader sends is referred to as the
NCGbyte, in the case of the GR47 it is C in ASCII.
2.3.1.2 The Actual Transfer
The uploader waits until the downloader sends an NCG
byte. The NCG byte is the signal that the downloader is
ready to start. If the downloader takes too long or an error
occurs then the uploader time out after 20 seconds. If this
happens the file transfer must be restarted (a CAN byte is
sent by the module and an error code is output)
Each packet consists of the following elements:
1 SOH byte (1 byte)
2 The packet number (1 byte)
3 The 1's complement of the packet number (1 byte)
4 The packet (128 bytes)
5 The high byte of the CRC-16 (1 byte)
6 The low byte of the CRC-16 (1 byte)
Note! The CRC is calculated on the data packet only not
including the header. The CRC is also sent little-endian so
above should be 5 low byte CRC, 6 high byte CRC.
The downloader:
1. Ensures that the packet number sent matches the
actual packet number received (If the third block sent
has a '4' as the second byte, something is wrong -->
CANCEL TRANSFER (send CAN byte)).
2. Adds the packet number and the 1's complement of it
together to make sure that they add up to 255. If they
don't --> CANCEL TRANSFER.
3. Sets the CRC to 0xFFFFFFFF and then calculates the
CRC for the 128 bytes of data.
4. Compares the received CRC-16 with the calculated
one.
WRITING AN EMBEDDED APPLICATION LOADER
8
LZT 123 8094 R1A
5. If everything looks ok, then the downloader appends
the bytes in the packet to the file being created (sent).
The downloader then sends an ACK byte which tells
the uploader to send the next block. If the sums do not
match then the downloader sends an NAK byte which
tells the uploader to repeat transmission of the block.
When the uploader sends an EOT byte instead of an SOH
byte the downloader sends a NAK byte. If the uploader
sends another EOT immediately after that the downloader
sends an ACK byte and the transfer is complete.
The downloader can cancel the transfer at any time by
sending a CAN byte. The uploader can only cancel
between blocks by sending a CAN byte. It is
recommended that the application send anywhere
between 2 and 8 consecutive CAN bytes when a
download cancellation is required as some programs will
not let you abort if only 1 CAN byte is sent.
WRITING AN EMBEDDED APPLICATION LOADER
9
LZT 123 8094 R1A
2.4 SLP DLL tool
The figures for the first packet are calculated by the IDE
using the SLP.DLL file. In the file package contained on
the extranet (SLP_loader_code.zip) is the current version
of slp.dll, slpdll.lib and header files with all the required
definitions. This should make linking across to slp.dll quite
straightforward.
Loading...