A new bootloader application which allows remote firmware update for Seeeduino Stalker v2, using XBee Series 2 wireless communication


Into a Wireless Sensor Network (WSN) it is necessary to have the possibility of remote firmware update for the devices (nodes) of the network. If the remote update would not be possible we should go with a computer to each node device, connect to it, and rewrite the new firmware application, and this every time a bug is corrected into the application or a new functionality is added. This method is inconvenient since it could consume a lot of time (difficult maintenance process), and sometimes the nodes are difficult to reach, even not impossible (e.g. they are deployed into a building, on different heights and corners, or into a dangerous area).

The proposed WSN end node

The WSN solution proposed by us, in the actual postdoc research project, supposes that each end node of the network will be constructed using a Seeeduino Stalker V2.1, as main board, and an XBee Series 2 wired antenna 2mW as radio communication module (which implements the Zigbee protocol). The XBee module has 2 modes of communication: transparent mode and API mode. Even if in transparent mode it is easier to do the remote firmware update, the API mode is preferred since it is more professional, being recommended for complex applications. The API mode is based on using telegrams of data into a predefined format, where the type of telegram could be verified, additional communication information could be added and security ensured.

Fortunately the XBee modules could be configured for using a pin (DO3) as digital output to reset the micro-controller (ATmega 328p – from high level it passes to a low level for a short period of time) and in this way the micro-controller will execute the boot-loader application. Only from boot-loader application it is possible to parse the telegrams received from the XBee module (serial communication), take the useful data from them and write them into the Flash memory. At this type of micro-controllers the firmware application has to be written into the Flash memory from the address 0x0000.

Seeeduinoboot – proposed bootloader for Seeeduino Stalker

To create the new version of bootloader application, with the required functionality, we have started to modify the Optiboot v4.4 application (a bootloader optimized for Arduino, and to which many people have contributed – more details: – I want to thank them for the open sources of Optiboot application and for the good job they have done).

A software application installed on the computer, connected to the WSN, should send the content of the new firmware application, through the coordinator node, to the selected destination node. In our case this software application is part of a bigger system and the update functionality has been developed into a single dialog (window) from where the user has the ability to select the hex file (Intel HEX file format, generated with Arduino environment) which contains the new firmware application. The firmware file is parsed line by line and for each line a XBee telegram is created and then sent to the destination node. The format of the telegram is:

|| start byte    ||  length || frame type || 64bit sender address || 16 bit sender address || options || request type || payload id || start address || record type || data || checksum ||
|| 1 byte (0x7E) || 2 bytes || 1 byte     || 8 bytes              || 2 bytes              || 1 byte  || 1 byte || 1 byte || 2 bytes || 1 byte || n bytes || 1 byte ||

At the destination node the boot-loader application receives the telegrams and do the necessary stuff (save the proper Flash page into a temporary buffer, erase Flash page, update the temporary buffer and rewrite the Flash page). At each telegram received it is sent back a response in which it is specified the success or failure of the update operation. Because to the large size of a firmware file it could not be send into a single telegram, but piece by piece. The maximum length of the Zigbee transmit telegram is limited.

Important settings (lock bits)
For allowing to the boot-loader application to write the Flash memory I have set all the lock bits as NO_LOCK, using the programmer AVR mkII, before writing the new bootloader application on the micro-controller.

Future updates
* erase the entire Flash memory (except boot section) of micro-controller before writing a new firmware application;
* make a compression of the firmware (if possible) for having less wireless traffic (decrease the energy consumption of the device);
* verify if the boot-loader has received the entire firmware application and not only a part of it;
* the _record type_ byte from the telegram should be eliminated since it is not used anymore;
* and more other options to be added later…


I’m not an expert in doing/modifying such kind of applications. I tried my best. So any helpful comments or ideas to improve this version of boot-loader will be very appreciated. Thank you! 🙂

Link to Google code page:

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: