Over the air firmware upgrade of deployed sensor nodes

The WiSense stack does not currently support over the air firmware upgrade. I intend to add this feature soon. I am going to go over the design and implementation of this feature in a series of posts.

One very important requirement for wireless sensor networks is the ability to upgrade the firmware on the sensor nodes which are already deployed in the field. If the network does not have this capability, it is going to be very painful to upgrade the firmware on each node in the network. Firmware upgrade may be required for the reasons listed below:

  • Bug fixing
  • Some feature may need modification
  • A new feature needs to be added
  • The application running on the node needs to be enhanced / modified

WiSense nodes are controlled by the MSP430G2955 16 bit microcontroller from TI.  The size of the on chip (MSP430G2955) flash memory is 56 KB. So, the maximum size of the firmware (including code, read only data and initialized data) can be max 56 KB. This includes the application layer.

We can divide the upgrade into two categories:

  • Update the whole firmware
  • Upgrade only the application running on the node.

The first category involves upgrading the complete firmware on a node (including the application).

The second category involves upgrading just the application. Typically WiSense nodes run a single application. This upgrade is more complicated since the new application object file has to be linked with the rest of the firmware already present in the node’s flash.

Let us list the challenges involved in implementing firmware upgrade:

  1. Get the image (the whole firmware or just the app layer) from the external world to the node to be upgraded.
  2. Support application upgrade only.
  3. The network should be able to support unicast, multicast (multiple nodes) and broadcast upgrade (all nodes).
  4. Need some external memory (i2c or SPI eeprom) to store the new image.
  5. The micro-controller should be able to support self reprogramming of the on-board flash memory using the image stored in the external EEPROM.

Let me address each of the challenges above.

  • The image can be transferred in chunks (chunk size limited by the maximum allowed MAC PDU length). There are many ways to reduce the amount of traffic required to upgrade a set of nodes.
  • Application only upgrade is more complicated. One can create a separate “app-only” section in the on-board FLASH for application code and read only data. When the node (being upgraded) receives the new application only image, it can erase this “app-only” section and write the new application image to this section. The rest of the firmware can remain undisturbed in a separate section on the flash. Rest of the firmware needs to call app layer functions indirectly (through a table of function pointers).  The application layer will have some restrictions on defining writable global variables. I am not sure at this point but looks like the application will not be able to define global writable variables. It has to define all such variables in a single structure and allocate memory for the structure during run time (app initialization).
  • Multicast upgrade can be supported by using the MAC layer multicast addressing mechanism and adding the ability to invite specific nodes to join a multicast group.
  • Broadcast upgrade can be supported by using the MAC layer broadcast address.
  • We plan to add a 128 KB I2C EEPROM to the micro-controller board. Received image chunks will be written to the EEPROM.
  • The MSP430 family allows self programming of the on board flash memory.

What if the new image contains changes in the routing protocol or the MAC layer ? We need to be really careful in this case. We want the specified node or set of nodes to rejoin the network after the upgrade otherwise what is the point. One strategy is to make sure that the new image is sent out to all the involved nodes. Then the nodes which are farthest are requested to perform the upgrade and restart followed by nodes which are closer to the coordinator and finally upgrade the coordinator itelf (if required). This way all nodes receive the new image followed by the request to upgrade.

So it looks like this is doable but as usual the devil is in the details.

Posted on January 4, 2015, in Uncategorized. Bookmark the permalink. Leave a comment.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: