Issue 1.

0 9356933

NOKIA M2M PLATFORM

REMOTE APPLICATION MODULE
Copyright © 2003 Nokia. All rights reserved.

UPDATE
PROGRAMMING GUIDE
Contents

ACRONYMS AND TERMS ...................................................................................................... 1

1. ABOUT THIS DOCUMENT .............................................................................................. 2
2. REMOTE AM UPDATE SYSTEM .................................................................................... 3
2.1 COMPONENTS ......................................................................................................... 3
2.2 REQUIREMENTS AND RECOMMENDATIONS ....................................................... 4
3. REMOTE AM UPDATE PROCEDURE ............................................................................ 7
3.1 OVERVIEW OF THE UPDATE PROCEDURE .......................................................... 7
3.2 MESSAGE SEQUENCING ........................................................................................ 9
3.3 MESSAGE FORMATS............................................................................................. 12
4. REMOTE AM UPDATE API ........................................................................................... 15
4.1 REMOTE AM UPDATE API CLASSES ................................................................... 15
4.2 CONFIGURING THE CORBA NAMING SERVICE ................................................. 15
4.3 INITIALIZING THE CORBA ORB ............................................................................ 16
4.4 LISTENING TO MESSAGES AND EVENTS ........................................................... 17
4.5 INITIALIZING AND STARTING THE REMOTE AM UPDATE API .......................... 18
4.6 USING THE REMOTE AM UPDATE API ................................................................ 19
5. REFERENCE IMPLEMENTATION ................................................................................ 21
5.1 PRELIMINARY INFORMATION .............................................................................. 21
5.2 DESCRIPTION OF THE REFERENCE IMPLEMENTATION .................................. 21
5.3 CONFIGURING THE REFERENCE IMPLEMENTATION PARAMETERS ............. 22
5.4 MANAGING TARGET INFORMATION.................................................................... 24
5.5 STARTING THE REMOTE AM UPDATE PROCEDURE ........................................ 26
5.6 VIEWING THE REFERENCE IMPLEMENTATION LOG ........................................ 27
APPENDIX A: REMOTE AM UPDATE CORBA INTERFACE ............................................... 28
APPENDIX B: REMOTE AM UPDATE PROTOCOL ............................................................. 32
1. MESSAGE DESCRIPTIONS.......................................................................................... 32
2. SYMBOL INFORMATION .............................................................................................. 38
Legal Notice
Copyright © 2003 Nokia. All rights reserved.
Reproduction, transfer, distribution or storage of part or all of the contents in this document in any form without the
prior written permission of Nokia is prohibited.
Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Java and all Java-based
marks are trademarks or registered trademarks of Sun Microsystems, Inc. Other product and company names
mentioned herein may be trademarks or trade names of their respective owners.
Nokia operates a policy of continuous development. Nokia reserves the right to make changes and improvements
to any of the products described in this document without prior notice.
Under no circumstances shall Nokia be responsible for any loss of data or income or any special, incidental,
consequential or indirect damages howsoever caused.
The contents of this document are provided "as is". Except as required by applicable law, no warranties of any
kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness
for a particular purpose, are made in relation to the accuracy, reliability or contents of this document. Nokia
reserves the right to revise this document or withdraw it at any time without prior notice.
ACRONYMS AND TERMS

Acronym/term Description
AM Application Module
API Application Programming Interface
CORBA Common Object Request Broker Architecture
CSD Circuit Switched Data
CTS Clear-to-Send. A serial communication signal.
DIS Device Information Storage
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GUI Graphical User Interface
M2M Machine-to-Machine
OMG Object Management Group
ORB Object Request Broker
OTA Over-the-Air
RTS Request-to-Send. A serial communication signal.
TCP Transmission Control Protocol
UI User Interface
VM Virtual Machine

1/39
1. ABOUT THIS DOCUMENT
This document describes the Remote Application Module (AM) Update feature
used in the Nokia M2M Platform, and gives guidelines on how to design and
implement its components. The document also presents a reference
implementation for performing the Remote AM Update.

Note: If you are not familiar with the Nokia M2M Platform terminology or
application development for the Platform, please familiarise yourself with the
Nokia M2M Platform Software Developer’s Guide before reading this document.

2/39
2. REMOTE AM UPDATE SYSTEM
This chapter gives an overview of the Remote AM Update system that can be
used on the Nokia M2M Platform for updating AM firmware Over-the-Air (OTA).
The requirements and recommendations for implementing the Remote AM
Update system are also listed here.

2.1 COMPONENTS
The Remote AM Update system incorporates the following components:
customer server application, Nokia M2M Gateway, and customer remote
application. The customer remote application consists of a Nokia 12 GSM
module (hereon Nokia 12 module) and AM that contains the application-specific
firmware to be updated (see Figure 1).

Server Nokia Customer remote

M2M application
Gateway
Application
Module
Customer server Remote AM
application* Update bootloader*

Remote
API
AM Update
calls
Protocol

Remote AM CORBA Remote AM Update

Update API CORBA Servant

Nokia 12
GSM module

*Customer-implemented parts

Figure 1. Components of the Remote AM Update system

The customer-implemented parts in this system are the software that uses the
Remote AM Update Application Programming Interface (API) in the customer
server application and the Remote AM Update bootloader that is located in the
AM.

3/39
 The Remote AM Update API is a CORBA client application implementation that
is used by the customer server application to control the whole update
procedure via the Gateway and Nokia 12 module. If you do not wish to use the
Remote AM Update API, you can develop your own CORBA client application
that uses the CORBA interface directly. For more information on the Remote
AM Update API and the reference implementation that uses it, please refer to
Chapters 4 and 5.

The Nokia 12 module has an integrated Remote AM Update CORBA Servant

functioning as a proxy. It translates messages coming from the API to a suitable
format for the bootloader. The CORBA Servant has two interfaces: Remote AM
Update CORBA interface and Remote AM Update Protocol. The CORBA
interface is used for communicating with the customer server application and
the Remote AM Update Protocol is used for communicating with the bootloader.

The bootloader is part of the AM software. The bootloader code implements the
Remote AM Update procedure in the AM. It facilitates communication with the
CORBA Servant, receives new firmware, erases the non-volatile memory of the
AM, and writes new firmware into it. A reference implementation of the
bootloader is available from Forum Nokia at
http://www.forum.nokia.com/main.html under Nokia M2M.

2.2 REQUIREMENTS AND RECOMMENDATIONS

Hardware requirements
• The AM must have a processor with an access to field erasable /
programmable memory (typically flash).
• The AM must have a serial connection to the M2M System Protocol port
(port 2) of the Nokia 12 module because the same port is used for the
Remote AM Update Protocol. Note that the M2M System Protocol remains
active in the port until the update procedure is started.
• The AM reset line must be connected to the corresponding pin of the M2M
System Connector in the Nokia 12 module. The line is active low. Check the
pin configuration of the M2M System Connector from the Integrator’s
Manual for Nokia 12 GSM Module.
• The AM reset line must have a switch for the local AM update option, for
example, during development phase when the AM firmware is updated via
wired connection. The M2M System Protocol alive check in the Nokia 12
module resets the AM processor if it stops sending the M2M System
Protocol.

4/39
Software requirements
• The customer server application and Nokia 12 module must be correctly
configured to enable communication with the Gateway. For more
information on correct configuration, please refer to the Nokia M2M Platform
Configuration Manual.
• The M2M System Protocol must be configured to port 2 of the Nokia 12
module.
• The AM must support the launch of the update procedure by the Nokia 12
module via serial connection, and the serial connection parameters must be
set as follows:
− Baud rate (same as configured for the M2M System Protocol)
− 8 data bits
− No handshake
− 1 parity bit
• The AM software must have a separate bootloader that is launched when
the AM is reset.
• The AM must respond to requests within 90 seconds. Otherwise a timeout
exception is thrown.
• The AM must report the Remote AM Update Protocol version to the Nokia
12 module at the beginning of the update procedure. This data is needed to
ensure that both the AM and the Nokia 12 module use the same version.
• The AM must implement the Remote AM Update Protocol.
• If the Nokia 12 module has active IMlets, they must be stopped for the
duration of the update procedure. For more information on IMlets, please
refer to the Nokia M2M Platform Java™ IMlet Loading Component User
Guide.
• If the AM has a hardware-based watchdog, it must be disabled for the
duration of the update procedure.

Recommendations
• The bootloader should be overwrite-protected (even in failure cases).
• Application development and testing of the Remote AM Update feature is
easier when using a Test board designed for the Nokia 12 module.
• The firmware file should be encrypted before the Remote AM Update.
• Communication between the customer server application and AM should
include checksums.
• The customer server application and bootloader should be developed
together so that common parameters like transmission configuration and
timing information will match. For example, if the AM flash memory is 32 bits

5/39
 wide, the packet size should be divisible by 4, and if it is16 bits wide, the
packet size should be divisible by 2.

Note: The Nokia 12 module does not use serial hardware handshake signals
during the update procedure. Instead, a Clear-to-Send (CTS) signal is set as
active throughout the procedure and the Request-to-Send (RTS) signal is ignored.

6/39
3. REMOTE AM UPDATE PROCEDURE
This chapter presents the Remote AM Update procedure.

3.1 OVERVIEW OF THE UPDATE PROCEDURE

Before starting the update procedure, it is important to know the operating
status of the AM because it may have ongoing critical operations or
transactions that must not be interrupted. Thus, the customer server application
and the AM must first negotiate whether the update procedure can be started.

The negotiation phase requires that the customer server application has a
connection to the AM and it is able to resolve when a reset is allowed.
Resolving the operating status depends on how the Nokia 12 module is used,
and its implementation is up to the customer.

The update procedure proceeds as follows (refer also to Figure 2):

1. Checking and preparing the AM status.

2. Starting the Remote AM Update.

3. Interrupting M2M System Protocol.

4. Updating the firmware block by block.

5. Finishing the Remote AM Update.

6. Restoring M2M System Protocol.

7. Checking that the update procedure was completed successfully and the
AM is working properly.

7/39
Customer server Nokia 12 GSM Application
application module Module
Remote AM Update Remote AM Update Remote AM Update
API CORBA Servant bootloader

Start the Remote Interrupt M2M System Protocol

AM Update

Sectors Size
Update block 1 7 64 KB
(sectors 6 - 7) 6 64 KB
5 64 KB
4 64 KB
Update block 2
3 64 KB
(sector 3)
2 64 KB
Update block 3 1 64 KB
(sectors 0 - 1) 0 64 KB

Finish the Remote

AM Update Restore M2M System Protocol

Figure 2. Overview of the Remote AM Update procedure

When the AM is ready for firmware update, the customer server application
requests the Nokia 12 module to enter the Remote AM Update mode. Because
the Remote AM Update Protocol and M2M System Protocol use the same
serial port, the Nokia 12 module suspends the M2M System Protocol operation
and all messages under transmission are cancelled. Any attempt to
communicate with the AM during the update procedure via the M2M System
Protocol results in an exception or service denial.

Note: All the output pins of the Nokia 12 module (including the AM reset line) are
reserved during the update procedure.

During the update procedure the customer server application commands the
bootloader to erase its non-volatile memory. The memory can be divided into

8/39
 sectors that can be erased and programmed separately. In Figure 2, the non-
volatile memory of the AM has 8 sectors, each sector having the size of 64
KBs. Multiple sectors in a continuous sequential order form a block and one
firmware file to be downloaded can contain one or more blocks.

The customer server application splits the firmware file into small pieces called
packets. These packets are then transferred to the bootloader and the
bootloader writes the packets into the non-volatile memory of the AM.

When the update procedure for all the blocks has been completed successfully,
the customer server application requests the Nokia 12 module to exit the
Remote AM Update mode. The Nokia 12 module resets the AM and restores
the M2M System Protocol operation. An exit is requested also in the case of a
failure. A new update procedure cannot be started before the ongoing
procedure has been finished.

When the AM has undergone a normal boot-up, it returns to its normal

operation mode. It is up to the customer server application to check that the AM
is working properly with the freshly updated firmware. Since this is an
application-specific feature, its implementation is beyond the scope of this
document.

It is important that the update procedure can be restarted or interrupted at any

phase because the GSM network may have temporary interrupts and error
situations that affect the update procedure.

3.2 MESSAGE SEQUENCING

This chapter presents the message sequencing between the CORBA and
Remote AM Update Protocol interfaces during the update procedure.
Messages, data structures, and status values of these interfaces are described
in more detail in Appendix A: Remote AM Update CORBA interface and
Appendix B: Remote AM Update Protocol, respectively.

Figure 3 shows the message sequencing during the update procedure.

9/39
 Customer server Nokia 12 GSM Application
application module Module
Remote AM Remote AM Update Remte AM
Update API CORBA Servant Update bootloader

prepare

Interrupt M2M System Protocol

Return Loader object
Reset AM to switch to the
startBlock Remote AM Update mode

{1s <t<2s}

transmit(FFh:Byte, 55h:byte)

transmit(FFh:Byte, AAh:byte)

FLASH_VERSION_GET_COMMAND()

FLASH_VERSION_GET_RESPONSE()
Repeated for each block

FLASH_INIT_DOWNLOAD_COMMAND()

FLASH_INIT_DOWNLOAD_RESPONSE()
Return device information
eraseBlock
FLASH_ERASE_COMMAND()
Repeated for each data packet

FLASH_ERASE RESPONSE()
Return

loadPacket FLASH_DOWNLOAD_DATA_COMMAND()
FLASH_DOWNLOAD_DATA_RESPONSE()
Return

completeBlock
FLASH_EXIT_DOWNLOAD_COMMAND()

FLASH_EXIT_DOWNLOAD_RESPONSE()
Return checksum
Reset AM to return to the
exit normal operation mode

Restore M2M System Protocol

Return

Figure 3. Message sequencing during the Remote AM Update procedure

The CORBA Servant resets the AM and requests a firmware update with a
simple handshaking. The bootloader replies to the handshake and the CORBA
Servant commands the bootloader to send the version data. If the version data
is incorrect, the CORBA Servant cancels the update procedure.

10/39
 The CORBA Servant controls the bootloader with the Remote AM Update
Protocol that is used for the actual firmware update. The protocol is
synchronous: the CORBA Servant sends a command message and the
bootloader replies with a response message.

The update procedure is fairly straightforward; only the packet transfer

message is repeated several times because the firmware is transferred in
packets. If the firmware to be updated has more than one block, the update
procedure must be executed for each block.

Note: The AM must send a response message to each command message within
90 seconds or a CORBA timeout exception occurs. To avoid the exception, the
firmware can be updated in multiple blocks, and a smaller block size can also be
used.

All the messages form a COMMAND/RESPONSE pair and all error handling
information is contained in the RESPONSE message’s status field (see
Appendix B: Remote AM Update Protocol). If the bootloader and the customer
server application fail to keep the update protocol in synchrony (meaning that
the two components are in different states) and the bootloader receives an
unknown COMMAND message, the bootloader simply ignores the message
and expects the customer server application to resolve the failure situation.

Table 1. Command messages

Command
FLASH_VERSION_GET_COMMAND
FLASH_INIT_DOWNLOAD_COMMAND
FLASH_ERASE_COMMAND
FLASH_DOWNLOAD_DATA_COMMAND
FLASH_EXIT_DOWNLOAD_COMMAND
Description
Get the version data.
Initialize the block update.
Erase the block.
Transfer the block data.
Finish the block update.

Table 2. Response messages

Command
FLASH_VERSION_GET_RESPONSE
FLASH_INIT_DOWNLOAD_RESPONSE
FLASH_ERASE_RESPONSE
FLASH_DOWNLOAD_DATA_RESPONSE
FLASH_EXIT_DOWLOAD_RESPONSE
Description
Deliver the version data.
Deliver the initialization data.
Report the erase status.
Report the packet transfer
status.
Report the block transfer
status.

11/39
3.3 MESSAGE FORMATS
Two different message formats are used between the CORBA Servant and the
bootloader. A handshake format is used to select the bootloader. A control
format is used to control the bootloader during the actual update procedure.
The bootloader must support both of these formats.

Handshake format
The handshake format has start and stop bytes. These bytes indicate the
beginning and end of the frame, respectively. Figure 4 presents the receiving
procedure for the handshake format from the viewpoint of the bootloader.

/ start byte :=FFh,stop byte:= 55h

Waiting for start byte

[else]

Handshaking
frame
[received start byte AND next byte is not the start byte
Start byte
Stop byte
Receiving message

[else] / store byte

FFh 55h

stop byte

Message received

Figure 4. Receiving procedure for the handshake format

Figure 4 also shows a handshaking frame with a start byte (FFh) and stop byte
(55h). When the Remote AM Update is requested, the CORBA Servant sends
the handshake message to the bootloader and waits for a handshake response
message. The response message includes a start byte (FFh) and stop byte
(AAh).

12/39
 Control format
Control format messages are prefixed with 12 start bytes for error recovery and
synchronisation. The start bytes indicate only the message frame start and they
can thus be ignored in message handling. Stop bytes are not used; instead the
control format has two bytes for packet length in a fixed position (2) to indicate
the number of bytes belonging to that packet after the length field. Message
length position counting starts from the first received byte after the start byte.
Figure 5 presents the receiving procedure for the control format from the
viewpoint of the bootloader.

/length position :=2,start byte:= FEh

Waiting for start byte

[else] An example of variable

length protocol frame

Start byte
[received start byte AND next byte is not the start byte Beginning End
Message

Waiting for length FEh 0Ah 00h 01h 0Bh

[else] / store byte Length

[length received] / calculate length,store byte

If length is nil (0)

there is no message
Receiving message data

[length received] / store byte

Message received

Figure 5. Receiving procedure for the control format

13/39
Figure 5 also shows an example of a control format message. This message
includes a start byte (FEh) and message data ({0Ah, 00h, 01h, 0Bh}). The
message length is 01 because the control protocol length position is defined to
be a constant (2) in the control format sending procedure in the CORBA
Servant.

14/39
4. REMOTE AM UPDATE API
The Remote AM Update API is a Java™-based software component that
incorporates methods to perform Remote AM Update in the customer’s Java
server application. The Remote AM Update API wraps many of the functions of
the Remote AM Update procedure, for example, using the CORBA object
interface from the Nokia 12 module.

The Remote Update API also contains a reference implementation with a

Graphical User Interface (GUI) that uses the Remote Update API directly. This
reference implementation can be used to perform the Remote AM Update to a
Hitachi H8S processor. For more information on the reference implementation,
see Chapter 5.

The Remote AM Update API is delivered with the Nokia M2M Gateway
Corporate Edition and Gateway Access Software (used with the Nokia M2M
Gateway Service Provider Edition).

If you do not wish to use the Remote AM Update API, you must use the
CORBA interface description (see Appendix A: Remote AM Update CORBA
interface) to implement the customer server application.

4.1 REMOTE AM UPDATE API CLASSES

The Remote AM Update API classes are included in the
AMDownloadComponent.jar file. They can be found from the
com.nokia.m2m.amdownload package.

The main class that contains the update methods is called

AmDownloadComponent. Other important classes that control the update
procedure are called Target, AmSoftwareBlock, and
AmSoftwareBlockPacket.

The Target object contains device information for the target Nokia 12 module
including the communication bearer – typically General Packet Radio Service
(GPRS) or Circuit Switched Data (CSD). The AmSoftwareBlock object
contains the data of the block to be updated to the AM and the
AmSoftwareBlockPacket objects.

4.2 CONFIGURING THE CORBA NAMING SERVICE

The Remote AM Update API must use the same CORBA Naming Service with
the Corporate Edition or the Gateway Access Software.

15/39
 Example: how to make an initial reference while starting the Remote AM
Update when using the Service Provider Edition and Gateway Access
Software
The Gateway Access Software runs on a different workstation from the API,
and the Device Information Storage (DIS) is registered into a CORBA Naming
Service that runs on the same host with the Gateway Access Software.

Setting the ORBInitRef.NameService property as the Virtual Machine (VM)

system attribute for Sun ORB:
java -DORBInitRef.NameService =
corbaloc::192.168.1.1:9999/NameService
MyRemoteUpdateApplication

The CORBA Naming Service reference is used from host 192.168.1.1, and the
Gateway Access Software uses a default port 9999 for the Naming Service.

You can set a location for the CORBA Naming Service also using System
Properties.

Example: how to configure the CORBA Naming Service location using

System Properties
// Initializing the CORBA Naming Service location (Sun ORB)
java.util.Properties properties = System.getProperties();
properties.put("ORBInitRef.NameService",
"corbaloc::192.168.1.1:9999/NameService");

4.3 INITIALIZING THE CORBA ORB

You can configure the Remote AM Update API with an ORB that has already
been initialized in your own application. This procedure is optional. If you do not
initialize the ORB, the Remote AM Update API tries to initialize it automatically
based on the Java System Properties.

Initialize the ORB and set the ORB reference into the Remote AM Update API
using the setOrb(ORB) method.

Configuring the Remote AM Update API with the CORBA ORB

// Creating a Loader object
AmDownloadComponent amLoaderAPI = new AmDownloadComponent ();

// Setting the CORBA Naming Service corbaloc

java.util.Properties properties = System.getProperties();
properties.setProperty("ORBInitRef.NameService",
"corbaloc::192.168.1.1:9999/NameService");
// Initializing the ORB (ORB classes set in the System Properties)
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init((String[])null, properties);

16/39
 // Delivering the ORB reference to the Remote AM Update API
amLoaderAPI.setOrb(orb);

4.4 LISTENING TO MESSAGES AND EVENTS

To write messages and send events, the Remote AM Update API uses the
com.nokia.m2m.amdownload.AmDownloadComponentListener interface.

The interface methods to be implemented are:

• amDownloadCompleted(AmDownloadData data, AmDownloadResult

result)
• logMessage(int iLogLevel, String sLogMessage)

The Remote AM Update API calls the amDownloadCompleted() method when

the AM update for one block is completed .

The AmDownloadData object includes the Target object and

AMSoftwareBlock object lists.

The AmDownloadResult object includes the AmDownloadResultItem object

list that contains information on the update procedure in different configuration
phases.

Listening to configuration events from the Remote AM Update API

public void amDownloadCompleted(AMDownloadData data,
AmDownloadResult result)
{
System.out.println("Downloading completed to target " +
data.getTarget().getTerminalId());
AmDownloadResultItem[] resultItemArray =
result.getResultItems();

// Printing the results

for(int i=0;i<resultItemArray.length;i++)
{
System.out.println("- " +
resultItemArray[i].getPosition() + "\t"
+ resultItemArray[i].getDescription() + "\t"
+ resultItemArray[i].getTimeStamp().toString() );
}
}

The logMessage() method is used to print messages generated by the Remote

AM Update API. The log level defines the amount of messages received. If the
log level is set to ‘3’, the method receives log messages that are on level 0,1,2,
or 3.

The default log level is ‘0’.

17/39
 Log level descriptions:

• 0 = Fatal Error
• 1 = Error
• 2 = Warning
• 3 = Note
• 4 = Debug

Listening to log messages from the Remote AM Update API

public void logMessage(int iLogLevel, String sLogMessage)
{
System.out.println("Update App Log [:" + iLogLevel + "] "
+ sLogMessage);
}

4.5 INITIALIZING AND STARTING THE REMOTE AM UPDATE API

To initialize and start the Remote AM Update API:

1. Create the Remote AM Update API object from the AmDownloadComponent
class.

2. Set the listener and adjust the log level if necessary.

3. Start the Remote AM Update API.

Note: When you stop using the Remote AM Update API, you must close it with
the close() method of the AmDownloadComponent class. This method contains
the mechanisms for closing threads and connections.

Initializing and starting the Remote AM Update API

AmDownloadComponent amLoaderApi = new AmDownloadComponent();

java.util.Properties properties = System.getProperties();

// Initialize the CORBA Naming Service location of the Nokia M2M Gateway
properties.setProperty("ORBInitRef.NameService",
"corbaloc::192.168.1.1:9999/NameService");

// Initialize the CORBA ORB

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init((String[])null, properties);

amLoaderApi.setOrb(orb);

18/39
 amLoaderApi.setListener(new MyAmLoaderApiListener());
amLoaderApi.start();

4.6 USING THE REMOTE AM UPDATE API

To start the Remote AM Update procedure:

1. Configure the connection information for the target Nokia 12 module as
described in the Nokia M2M Platform Configuration Manual.

2. Configure the AM firmware blocks using the AM firmware block packets

from your AM firmware data.

3. Configure the Remote AM Update options.

4. Create an AmDownloadData object that contains the target Nokia 12

module, AM firmware blocks, and AM update parameters.

5. Start the Remote AM Update procedure using the AmDownloadComponent

class.

Initializing the target Nokia 12 module

// Initialize the target Nokia 12 module where the AM is connected to
// using the TCP GPRS connection bearer in communication.
Target amTarget =
new Target("term123", new Bearer("GPRS.TCP"));

Initializing the AM update data for the Remote AM Update API

// Initialize the update options
AmDownloadOptions amUpdateOptions = new AmDownloadOptions();
amUpdateOptions.setMaxPacketSize( 2046 );
amUpdateOptions.setEraseBlockBeforeLoad(true);

// Bytes are read from the AD-4 sample HEX file.

IntelFormatReader ir = new IntelFormatReader();
ir.readFile("NokiaAD4Sample.hex");

DataRecord record = ir.getData();

byte[] data = record.getData();

// Create the AM firmware block to be updated.

AmSoftwareBlock amSwBlock = new AmSoftwareBlock();

amSwBlock.setBlockAddress( record.getStartAddress() );

// Calculate and set the checksum of the block

amSwBlock.setCrc( CRC32.crc32(data) );
amSwBlock.setRunAddress(0);

19/39
 // Build a firmware packet list with a desired packet size.
DataRecord[] recs = ir.getDataRecords(amUpdateOptions.getMaxPacketSize());
for (int i=0; i<recs.length; i++)
{
// Put the packet data and the checksum (CRC) into the block.
amSwBlock.addAmSoftwareDataPacket(
recs[i].getData(),CRC32.crc32(recs[i].getData()) );
}

// Create the AM update data to be used in the Remote AM Update API.

AmDownloadData amUpdateData = new AmDownloadData();

// Set the target Nokia 12 module.

amUpdateData.setTarget(amTarget);

// Add the AM firmware block to be updated.

amUpdateData.addAmSoftwareBlock(amSwBlock);

// Set the update-specific options.

amUpdateData.setAmDownloadOptions(amUpdateOptions);

Updating the AM firmware

// Start the Remote AM Update with one data item.

// This method blocks until the update procedure is completed.
amLoaderApi.loadAmSoftware(amUpdateData);

Closing the Remote AM Update API

// Close the Remote AM Update API.

// The close method waits until all ongoing update procedures are
completed.
amLoaderApi.close(true);

20/39
5. REFERENCE IMPLEMENTATION
The Remote AM Update system includes a reference implementation with a
GUI that uses the Remote AM Update API. This chapter describes how to use
the reference implementation to perform the update procedure.

5.1 PRELIMINARY INFORMATION

You need the following preliminary information before starting the reference
implementation:

• Host information of the Corporate Edition or Gateway Access Software

(when using the Service Provider Edition)
− CORBA Naming Service location (corbaloc)
• Device information of the target Nokia 12 module
− Terminal ID in DIS
− Connection bearer type (GPRS.TCP or CSD.TCP)

5.2 DESCRIPTION OF THE REFERENCE IMPLEMENTATION

Start the reference implementation application with the following command:

“java -DORBInitRef.NameService
=corbaloc::localhost:9999/NameService
-Dorg.omg.CORBA.ORBInitialHost=localhost
-Dorg.omg.CORBA.ORBInitialPort=9999
com.nokia.m2m.amdownload.ui.AmDownloadUiApp -windows”

The system attributes define the location of the CORBA Naming Service of the
Corporate Edition or Gateway Access Software (localhost and 9999).

Note: The org.omg.CORBA.ORBInitialHost and

org.omg.CORBA.ORBInitialPort are Sun ORB specific attributes for locating the
CORBA Naming Service.

The command line argument windows indicates that the application starts the
GUI in the Windows ‘look and feel’ mode (other selectable arguments are
motif and metal).

21/39
 When you start the reference implementation application, the main window
presented in Figure 6 opens without any added information.

Figure 6. Main window of the reference implementation

5.3 CONFIGURING THE REFERENCE IMPLEMENTATION

PARAMETERS
The reference implementation configuration can be changed in the
Configuration dialog box. Open the dialog box by choosing the Configuration
command from the Tools menu.

Accept the new configuration by clicking OK. If you click Cancel, the
configuration changes are not saved. You can retrieve the recently saved
configuration by clicking Revert.

The saved configuration is used when the reference implementation is started

the next time.

Modifying component settings

In the Component Settings tab, you can modify the following parameters:

• AM Loader Object ID

22/39
 • User Information (in DIS)
• Bearer Information (in DIS)

The AM Loader Object ID indicates the object key of the AMLoader object in
the Nokia 12 module.

Note: If the AM Loader Object ID parameter does not match with the Nokia 12
module, the Remote AM Update procedure fails. Currently it is not recommended
to change this parameter.

The User Information parameter defines the name of the user information
database implementation in the CORBA Naming Service of the Corporate
Edition or Gateway Access Software. The reference implementation application
checks that the target Nokia 12 module exists in the user information database.

The Bearer Information parameter defines the name of the bearer information
database implementation in the CORBA Naming Service of the Corporate
Edition or Gateway Access Software. The reference implementation
application gets the valid communication bearers for the target Nokia 12
module from the bearer information database.

Figure 7. Component settings

23/39
 Modifying CORBA settings
The Remote AM Update feature can use various CORBA ORB
implementations. In the CORBA Settings tab, you can modify the following
parameters:

• ORB Class
• ORB Singleton
• Naming Service Corbaloc (CORBA Naming Service location of the
Corporate Edition or Gateway Access Software)

Note: With ORB Class and ORB Singleton parameters you can select the
CORBA ORB implementation. If the fields are left empty, the Sun ORB is used
(Java 2 version 1.4 or later)

Figure 8. CORBA settings

5.4 MANAGING TARGET INFORMATION

This chapter describes the management of Target Information in the reference
implementation.

Adding target Nokia 12 module information

The target Nokia 12 modules are added to the Target Information list. To add
a new Nokia 12 module to the list, click Add on the Target Information pane
(see Figure 6). A dialog box shown in Figure 9 opens.

24/39
Figure 9: Add Target Information dialog box

Enter the Terminal ID of the target Nokia 12 module into the text field and click
OK. The reference implementation automatically receives the Terminal ID
information from DIS, and the default bearer is selected for the update
procedure.

The Terminal ID, Bearer, and Bearer Port information of the Nokia 12 module is
now shown on the Target Information list.

The target Nokia 12 module must be found from DIS. In addition, at least one
bearer must be configured into DIS. If the required information is not found, the
Nokia 12 module is not accepted to the Target Information list.

Editing target Nokia 12 module information

If DIS has more than one bearer configured for the target Nokia 12 module, you
can change the bearer that is to be used in the update procedure.

To edit the existing target Nokia 12 module information, select the target from
the Target Information list and click Edit on the Target Information pane (see
Figure 6). A dialog box shown in Figure 10 opens.

25/39
 Figure 10: Edit Target Information dialog box

To change the bearer information, select the wanted value from the Bearer
combo box. The value in the Bearer combo box shows the bearer type and port
in the Nokia 12 module.

The Bearer combo box contains only those bearers that are configured into
DIS.

Information for only one Nokia 12 module can be edited at a time.

Removing Nokia 12 modules from the Target Information list

To remove a target Nokia 12 module from the Target Information list, select
the target from the list and click Remove on the Target Information pane.

Multiple Nokia 12 modules can be removed from the list at a time.

5.5 STARTING THE REMOTE AM UPDATE PROCEDURE

You must set at least one target into the Target information list before you can
initiate the update procedure.

Before starting the update procedure, set the path of the update firmware file to
the HEX filename field (see Figure 6). The Packet size and Run address
have their default property values set.

The Packet size parameter defines the maximum size of one packet of the
firmware block to be downloaded. One firmware block is thus downloaded in
one ore more packets depending on the block size. The Run address
parameter defines the address of the firmware where the bootloader starts the
application. For more information on using the Packet size and Run address
parameters, refer to Appendix B: Remote AM Update Protocol.

Start the update procedure by pressing the Start Downloading button on the
main window (see Figure 6).

26/39
5.6 VIEWING THE REFERENCE IMPLEMENTATION LOG
You can view the reference implementation log by selecting the View Log
command from the Tools menu.

The log contains information on the Remote AM Update API initialization and
AM firmware update procedure. The amount of log information depends on the
selected log level. For more information on the log levels, refer to Chapter 4.4.

The log information is also saved into a file, so it can be viewed even when the
reference implementation is closed.

Figure 11. Reference implementation log

27/39
APPENDIX A: REMOTE AM UPDATE CORBA INTERFACE
The CORBA interface contains two interfaces called Manager and Loader. The
Manager interface prepares the AM for the update procedure and the Loader
object performs firmware update for one or several blocks. The Manager
methods are described in Table 3 and the Loader methods in Table 4. For
more information on the interfaces, please refer to the CORBA interface
description at the end of this chapter and the Nokia GSM Connectivity Terminal
and Nokia 12 GSM Module Interface Definition Reference Guide.

A general exception is raised, if the update procedure does not proceed as

expected. The exception reason is identified according to enumerated values
described in Table 5.

Note: In addition to the general exception, any CORBA system exceptions can
also be thrown.

It is up to the customer server application to recover from possible failures. In

failure cases, the whole update procedure must be exited and restarted.

Table 3. Manager methods

Method Description
prepare This method prepares the Nokia 12 module for the
update procedure. The method returns a Loader
object. The Loader object must be exited (see
Table 4) before the next prepare is called or an
exception occurs.

Table 4. Loader methods

Method Description
startBlock This method starts the update procedure for a
specified AM firmware block. This method is also
called to restart the update procedure in the case
of a failure.
eraseBlock This method erases a specified AM firmware
block.
loadPacket This method transfers one packet to the AM.
completeBlock This method is called to indicate that all packets
have been transferred to the AM and the update of
one block is completed. After this call the Loader
object is completed.
exit This method is called when the Loader object is
completed and all blocks have been updated. This

28/39
 Method Description
method can also be called to interrupt the update
procedure in the case of a failure.
Note! In the case of an interrupt, the AM may not
be operational.

Table 5. Exceptions
Exception Description
GENERAL_EXCEPTION General failure (currently reserved).
CORBA_EXCEPTION CORBA failure (currently reserved).
AMDL_ERROR Internal failure in the Nokia 12 module.
AMDL_AM_ERROR Nokia 12 module was unable to handle a
bootloader failure.
AMDL_ERROR_ONGOING Nokia 12 module has an ongoing Remote AM
Update.
AMDL_ERROR_SERIAL_FAILURE Severe serial failure in the Nokia 12 module.
AMDL_ERROR_INVALID_SEQUENCE Update message sequence of the Nokia 12
module was incorrect.
AMDL_SYSTEM_BUSY Nokia 12 module is busy.
AMDL_ERROR_RESPONSE_TIMEOUT Nokia 12 module did not receive a response
from the bootloader before a set time.
AMDL_ERROR_PACKET_SIZE_INCORRECT Nokia 12 module was unable to handle the
firmware packet size.
AM_ERROR Internal failure of the bootloader.
AM_INIT_ERROR_PACKAGE_TOO_BIG The AM memory size was too small
compared to the firmware.
AM_INIT_ERROR_ILLEGAL_ADDRESS The requested AM memory address was
illegal.
AM_ERASE_ERROR The bootloader was unable to properly erase
the memory.
AM_DOWNLOAD_ERROR_PACKET_CRC_FAIL The bootloader has reported a checksum
failure for the firmware packet.
AM_ERASE_ERROR_BLOCK_PROTECTED The AM memory block to be erased was
protected.
AM_DOWNLOAD_ERROR_WRITE_FAIL Write error of the AM memory.
AM_EXIT_ERROR Bootloader failure when exiting the Remote
AM Update.
AM_ERROR_PACKET_SIZE_INCORRECT The AM was unable to handle the packet
size.

29/39
Exception Description
AM_ERROR_RUN_ADDRESS_INCORRECT The AM run address was incorrect.

Remote AM Update CORBA interface description

module AMLoader
{
typedef sequence<octet> OctetArray;
typedef unsigned long blockCRC_T;

struct Version
{
octet major;
octet minor;
};

struct DeviceInformation
{
Version swVersion;
Version hwVersion;
Version protocolVersion;
unsigned short flashManufacturerId;
unsigned short flashDeviceId;
unsigned short packetSize;
unsigned long reserved;
};

enum ExceptionReason
{
GENERAL_EXCEPTION,
CORBA_EXCEPTION,
AMDL_ERROR,
AMDL_AM_ERROR,
AMDL_ERROR_ONGOING,
AMDL_ERROR_INVALID_PROTOCOL,
AMDL_ERROR_SERIAL_FAILURE,
AMDL_ERROR_INVALID_SEQUENCE,
AMDL_SYSTEM_BUSY,
AMDL_ERROR_RESPONSE_TIMEOUT,
AMDL_ERROR_PACKET_SIZE_INCORRECT,
AM_ERROR,
AM_INIT_ERROR_PACKAGE_TOO_BIG,
AM_INIT_ERROR_ILLEGAL_ADDRESS,
AM_ERASE_ERROR,
AM_DOWNLOAD_ERROR_PACKET_CRC_FAIL,
AM_ERASE_ERROR_BLOCK_PROTECTED,
AM_DOWNLOAD_ERROR_WRITE_FAIL,
AM_EXIT_ERROR,
AM_ERROR_PACKET_SIZE_INCORRECT,
AM_ERROR_RUN_ADDRESS_INCORRECT
};

exception GeneralException
{
ExceptionReason reason;
string description;
};

interface Loader

30/39
 {
DeviceInformation startBlock(
in unsigned long blockAddress,
in unsigned long blockSize
) raises (GeneralException);

void eraseBlock(
in unsigned long blockAddress,
in unsigned long blockSize
) raises (GeneralException);

void loadPacket(
in unsigned short packetSize,
in unsigned long packetAddress,
in unsigned long packetCRC,
in OctetArray data
) raises (GeneralException);

blockCRC_T completeBlock(
in unsigned long blockAddress,
in unsigned long blockSize,
in unsigned long runAddress,
in octet runAddressInUse,
in octet downloadComplete
) raises (GeneralException);

void exit() raises (GeneralException);

};

interface Manager
{
Loader prepare() raises (GeneralException);

};
};

31/39
APPENDIX B: REMOTE AM UPDATE PROTOCOL

1. MESSAGE DESCRIPTIONS
This chapter presents the COMMAND and RESPONSE messages related to
the Remote AM Update Protocol. The messages presented here are always
sent in the given order. In error situations, the CORBA Servant does not try to
restart the update procedure, but simply resets the AM.

The CORBA Servant delivers majority of the data contained in these messages
transparently to the customer server application.

Note: In the message description tables presented in this chapter, the numbers in
the value fields are given in a hexadecimal format.

Note: The Remote AM Update Protocol (and the reference implementation of the
bootloader) uses big endian byte order meaning that the most significant byte is
sent first

FLASH_VERSION_GET_COMMAND
The CORBA Servant sends this version request command after it has reset the
AM. The purpose of this command is to ensure that the AM hardware is
compatible with the firmware package, the bootloader is compatible with the
Remote AM Update Protocol, and the firmware version is old and needs to be
updated.

Table 6. FLASH_VERSION_GET_COMMAND
Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_VERSION_GET_COMMAND
2 Message size in bytes 0000h

FLASH_VERSION_GET_RESPONSE
The bootloader replies to the version request command with this response. The
version data contains the version of the Remote AM Update Protocol and other
version data as described in Table 7.

The CORBA Servant checks only the version of the Remote AM Update
Protocol. If the version is wrong, it will report an error to the customer server

32/39
 application, and then decides how to continue with the procedure. All the other
version data is handled in the customer server application.

Table 7. FLASH_VERSION_GET_RESPONSE
Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_VERSION_GET_RESPONSE
2 Message size in bytes 0010h
2 AM boot code SW version 0000h – FFFFh
2 AM HW version 0000h – FFFFh
2 Remote AM Update Protocol 0100h
version
(Major = 01h, Minor = 00h)
2 Flash manufacturer ID 0000h – FFFFh
2 Flash device ID 0000h – FFFFh
2 Reserved 0000h
4 Reserved 0000h

FLASH_INIT_DOWNLOAD_COMMAND
If the Remote AM Update Protocol version was correct, the CORBA Servant
sends this command. The block data contains the start address and byte size of
the block. The maximum size of data in a single packet is the maximum packet
size for the CORBA Servant.

Table 8. FLASH_INIT_DOWNLOAD_COMMAND
Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_INIT_DOWNLOAD_COMMAND
2 Message size in bytes 000Ah
4 Block start address 00000000h – FFFFFFFFh
4 Block size 00000001h – FFFFFFFFh
2 Maximum amount of bytes in a 00000001h – 1FF3h
single packet

33/39
 FLASH_INIT_DOWNLOAD_RESPONSE
The bootloader replies to the init command with this response. The data packet
size must be suitable for the bootloader. If it is greater than that given in the
FLASH_INIT_DOWNLOAD_COMMAND message, it will be reduced to the size
defined in this message. The customer server application can use an equal or
smaller packet size.

If the block is addressed to a wrong place (for example to a write-protected

block), the bootloader replies with an AM_INIT_ERROR_ILLEGAL_ADDRESS
status value.

If the block size does not fit into the block address, the bootloader replies with
an AM_INIT_ERROR_PACKAGE_TOO_BIG status value.

Table 9. FLASH_INIT_DOWNLOAD_RESPONSE
Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_INIT_DOWNLOAD_RESPONSE
2 Message size in bytes 0004h
2 Amount of data bytes to be 0001h – 1FF3h
used in the
FLASH_DOWNLOAD_DATA_
COMMAND for packet data.
2 Status AM_OK,
AM_INIT_ERROR_PACKAGE_TOO_BIG,
AM_INIT_ERROR_ILLEGAL_ADDRESS

FLASH_ERASE_COMMAND
The bootloader has now negotiated the Remote AM Update Protocol and the
block address and size are correct. Next the CORBA Servant commands the
bootloader to erase the specified block. The block address and size values are
the same as in the FLASH_INIT_DOWNLOAD_COMMAND.

Table 10. FLASH_ERASE_COMMAND

Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_ERASE_COMMAND
2 Message size in bytes 0008h
4 Block start address 00000000h – FFFFFFFFh
4 Block size 00000001h – FFFFFFFFh

34/39
 FLASH_ERASE_RESPONSE
The bootloader replies to the erase command with this response. If the erase
operation fails (for example verification shows that the specified block was not
erased), the bootloader replies with an AM_ERASE_ERROR status value.
Usually this indicates that the memory is damaged and must be changed.

If the erase operation was addressed to a write-protected address, the

bootloader replies with an AM_ERASE_ERROR_BLOCK_PROTECTED status
value.

Table 11. FLASH_ERASE_RESPONSE

Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_ERASE_RESPONSE
2 Message size in bytes 0002h
2 Status AM_OK,
AM_ERASE_ERROR,
AM_ERASE_ERROR_BLOCK_PROTECTED

FLASH_DOWNLOAD_DATA_COMMAND
The memory is now erased and can be updated. The CORBA Servant then
sends the download data command for each packet. The packet size is defined
by the customer server application and packet data is handled in bytes.

The packet data header contains the packet address and checksum. The
checksum is calculated by the customer server application and verified by the
bootloader. Thus, it is up to the customer to decide what kind of checksum
method is used, if any.

Table 12. FLASH_DOWNLOAD_DATA_COMMAND

Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_DOWNLOAD_DATA_COMMAND
2 Message size in bytes 000Ah + packet_size
4 Packet address 00000000h – FFFFFFFFh
4 Checksum 00000000h – FFFFFFFFh
2 Size of the data packet in packet_size*: 00001h – 1FF3h
bytes.
*packet_size Packet data Byte array

35/39
 FLASH_DOWNLOAD_DATA_RESPONSE
The bootloader replies to the download data command with this response. If the
bootloader detects that the checksum is incorrect, it replies with an
AM_DOWNLOAD_ERROR_PACKET_CRC_FAIL status value.

If the write verification fails, the bootloader replies with an

AM_DOWNLOAD_ERROR_WRITE_FAIL status value.

If the bootloader receives a packet that has a size greater than that negotiated
in the FLASH_INIT_DOWNLOAD_RESPONSE message, it replies with an
AM_DOWNLOAD_ERROR_PACKET_SIZE_INCORRECT status value.

Table 13. FLASH_DOWNLOAD_DATA_RESPONSE

Size in bytes Description Value
1 Message start MSG_START_MARK
mark
1 Message ID FLASH_DOWNLOAD_DATA_RESPONSE
2 Message size in 0002h
bytes
2 Status AM_OK,
AM_DOWNLOAD_ERROR_PACKET_CRC_FAIL,
AM_DOWNLOAD_ERROR_WRITE_FAIL,
AM_DOWNLOAD_ERROR_PACKET_SIZE_INCORRECT

FLASH_EXIT_DOWNLOAD_COMMAND
When all the data packets have been transferred, the CORBA Servant
commands the bootloader to exit the Remote AM Update mode. The bootloader
reacts according to the values of the block complete data.

Using a run address is optional. If the block complete data contains a run
address, the bootloader starts executing the code from that address. If the
block complete data contains a mark indicating that this block was the last
block, the bootloader typically halts and waits for a reset from the CORBA
Servant. If the given block was not the last block, the bootloader waits for a
FLASH_INIT_DOWNLOAD_COMMAND message for a new block.

Table 14. FLASH_EXIT_DOWNLOAD_COMMAND

Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_EXIT_DOWNLOAD_COMMAND
2 Message size in bytes 0010h

36/39
Size in bytes Description Value
4 Block start address 00000000h – FFFFFFFFh
4 Block size 00000001h – FFFFFFFFh
4 Run address 00000000h – FFFFFFFFh
2 Run address is in use TRUE, FALSE
2 This block is the last block TRUE, FALSE

FLASH_EXIT_DOWNLOAD_RESPONSE
The bootloader can calculate a checksum over the updated block and return it
to the customer server application in this response.

If the execute address is incorrect, the bootloader replies with an

AM_ERROR_RUN_ADDRESS_INCORRECT status value.

If an (customer-specified) error occurs, the bootloader may reply with an

AM_EXIT_ERROR status value.

Table 15. FLASH_EXIT_DOWNLOAD_RESPONSE

Size in bytes Description Value
1 Message start mark MSG_START_MARK
1 Message ID FLASH_EXIT_DOWNLOAD_RESPONSE
2 Message size in bytes 0006h
4 Checksum of the block 00000000h – FFFFFFFFh
2 Status AM_OK,
AM_ERROR_RUN_ADDRESS_INCORRECT,
AM_EXIT_ERROR

37/39
2. SYMBOL INFORMATION
This chapter presents the number values for symbolic constants used in the
Chapter 1.

Table 16. Message IDs

Message ID Value
FLASH_DOWNLOAD_DATA_COMMAND 44h
FLASH_DOWNLOAD_DATA_RESPONSE 64h
FLASH_ERASE_COMMAND 52h
FLASH_ERASE_RESPONSE 72h
FLASH_EXIT_DOWNLOAD_COMMAND 58h
FLASH_EXIT_DOWNLOAD_RESPONSE 78h
FLASH_INIT_DOWNLOAD_COMMAND 49h
FLASH_INIT_DOWNLOAD_RESPONSE 69h
FLASH_VERSION_GET_COMMAND 56h
FLASH_VERSION_GET_RESPONSE 76h

Table 17. AM statuses

Symbol ID Value Description
AM_OK 0001h General OK.
AM_ERROR 0002h General AM error.
AM_INIT_ERROR_PACKAGE_TOO_BIG 0003h The SW package file
was too big.
AM_INIT_ERROR_ILLEGAL_ADDRESS 0004h An illegal address.
AM_ERASE_ERROR 0005h The block could not be
erased.
AM_DOWNLOAD_ERROR_PACKET_CRC_FAIL 0006h The packet CRC
failed.
AM_ERASE_ERROR_BLOCK_PROTECTED 0007h The block could not be
erased because the
flash address was write
protected
AM_DOWNLOAD_ERROR_WRITE_FAIL 0008h Flash writing failed.
AM_EXIT_ERROR 0009h Failure during exit.
AM_DOWNLOAD_ERROR_PACKET_SIZE_INCORRECT 000Ah The packet size was
incorrect.

38/39
Symbol ID Value Description
AM_EXIT_ERROR_RUN_ADDRESS_INCORRECT 000Bh The run address was
incorrect

Table 18. Message start mark

Symbol ID Value Description
MSG_START_MARK FEh Flash protocol
message start mark
(byte).

39/39