Firmware Over the Air FOTA Updates

FOTA

We've got over-the-air firmware updates (FOTA) working for the platforms based on Nordic's nRF51822. This means that it is possible to update the firmware of an nRF51822 based device from a BLE-enabled smartphone (and hopefully soon from a development PC over a BLE dongle).

Presently, there is very little security or safety in this firmware-update process, but this is being worked upon.

We're also working on standardization of the FOTA protocol; and for defining a security model for validating/authenticating firmwares.

FOTA requires the use of a (Nordic-specific) DFU-bootloader to provide the functionality for firmware download and reprogramming. Once the DFU-bootloader is resident, any BLE application may be updated as long as the operation of the BLE stack isn't impaired.https://devzone.nordicsemi.com/documentation/nrf51/6.0.0/s110/html/a00062.html covers some more technical detail compared to what's written here.

Components Involved

The following image shows the layout of the main software components which go into a FOTA capable system. These include:

• Softdevice: this is Nordic's encapsulation of the bluetooth stack.
• Application: the user's BLE application.
• Bootloader: which is responsible for firmware updates.

Upon power-up, the softdevice initializes the system and forwards control to the bootloader. Unless it has been triggered to do firmware-updates, the bootloader forwards control to the application right-away.

The bootloader image needs to be installed initially; and thereafter the FOTA mechanism can update any DFU-service enabled application as long as it doesn't crash. The softdevice and the bootloader components don't change during FOTA updates; and therefore don't need to be combined with the firmware sent over the air.

Mbed platforms typically come with an interface chip, called CMSIS-DAP, which offers drag-n-drop based programming over USB. CMSIS-DAP does a complete chip-erase before programming new firmware, so binaries meant for USB drag-n-drop need to combine the softdevice with the application. FOTA offers a complementary programming facility where once the initial bootloader image is installed (possibly using CMSIS-DAP), further programming involves only updating the application while keeping the softdevice and the bootloader unchanged.

We'd like to re-emphasize that FOTA applications don't need to be combined with the softdevice (as is needed for stand-alone applications used with CMSIS-DAP). For this reason, FOTA applications need a separate (virtual) build target for each Nordic platform. be generated by building for 'shadow' platforms meant for FOTA.

Here are some links to these alternate/virtual platforms:

for mKit

for nRF-DK

Please be sure to add these platforms to your online compiler; and build for them when generating FOTA binaries.

Default Bootloader

Here's an initial image for the Nordic mKit to install the bootloader.

Here's the corresponding initial image for the nRF-DK platform.

Please unpack the appropriate .zip archive into a .hex file for programmed onto the target.

Together with the bootloader, these images come with a default application offering Device-Information and Console Output services.

You can find more information about the internals of the DFU bootloader at: http://developer.mbed.org/forum/team-63-Bluetooth-Low-Energy- community/topic/5201/.

Notes:

• When you change the services on a BLE Device during development you may need to refresh the Android MCP App's Service list by disconnecting and then reconnecting (otherwise it may be showing previously cached info for that BLE device)
• copy the hex file to the normal nRF51822 virtual USB drive which has file mbed.htm (not the drive when reset was held with mbed_bl.htm)

DFU Service

FOTA enabled applications work by offering a DFUService. This service contains a 'control' characteristic which when written to forwards program control to the resident bootloader in preparation for FOTA. This division of responsibility implies that FOTA applications need bear only a small overhead while keeping most of the FOTA heavy-lifting in the bootloader.

When building for a FOTA-enabled platform (see discussion on virtual/shadow platforms above), an instance of the DFUService gets added to an application implicitly during the call to ble.init(); the assumption being that for such a platform an application will always want to enable FOTA.

If an application built for a non-FOTA platform wishes to introduce the DFUService explicitly, it takes a single line of code to do so:

code changes needed to add DFU-Service

1
2
3
4
/* Enable over-the-air firmware updates. Instantiating DFUSservice introduces a
 * control characteristic which can be used to trigger the application to
 * handover control to a resident bootloader. */
DFUService dfu(ble);

In that case you will also need to include DFUService.h. An example of such use would be the creation of the initial application which goes with the bootloader.

Driving FOTA

Updating a FOTA-capable application is a two stage process. It involves triggering the application to hand over control to the bootloader, and then letting the bootloader receive and apply the udpate safely.

Sequence Diagram for Firmware Over The Air

This process can currently be driven from an external BLE agent such as an Android phone. We'll soon be releasing our own reference apps for iOS and Android; together with SDKs to build custom apps for FOTA. For the moment, we recommend using Nordic's nRF Master Control Panel as a generic tool to drive FOTA. https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp

Here's a video showing FOTA (starting at around 2:00).

The following sections provide snapshots of the process as driven by the Master Control Panel.

Lising the device with DFU Service

The following images (taken using Nordic's master-control-panel Android-app) expand on the capabilities of the defaultApp bundled into the initial bootloader image (mentioned above). Among other services, this application offers a DFU-Service which allows FOTA. All DFU-capable applications should offer this service.

• 
• 
• 

Triggering FOTA

The DFUService contains a single 'control-point' characteristic, which when written forces the application to enter DFU mode; internally it causes the application to forward control to the resident bootloader which takes over the firmware transfer.

The following set of images shows how Nordic's Master Control Panel can be used to cause a DFU capable application to forward control to the bootloader:

• 
• 
• 
• 
• 

Driving FOTA

And these images show the main FOTA sequence using the bootloader:

• 
• 
• 
• 
• 
• 
• 

At the end of this process, the new application is handed control automatically, and you can see it appear on the master-control-panel.

Attribute/Service Caching

You should be aware that to save energy a GATT client often caches the results from a service discovery. Changing/updating an application (especially when replacing it with a different application) may require the client to re- attempt service discovery. After a FOTA update, you may want to restart your client application, if this doesn't happen automatically; or restart the Bluetooth service on the client's system.

Limitations of FOTA

• There is no security or safety built into the process yet. Anyone with the right tools can update a FOTA capable target. Resolving this is very high on our priorities.
• Building FOTA binaries currently requires using a 'shadow' build platform for every target. We shouldn't be cloning build platforms for FOTA; ideally this should be a selectable option.
• FOTA requires installing an initial image containing the bootloader. For non-official mbed platforms, that would mean that a user would need to understand the internals well enough to be able to build an initial image, and also find a programming interface to transfer it to the target. We're working on releasing a USB->SWD adaptor which can target nRF51822 boards which don't have an mbed CMSIS-DAP interface.
• The two stage FOTA process is cumbersome and error-prone. We're working on creating a simple reference app to drive FOTA. Eventually we hope to release an SDK to allow users to create their own FOTA driver applications.

How does TI CC3000 wifi smart config work?

The ti cc3000 wifi chip has a special smart config mode, this is to allow the initial configuration of the wifi access details.

The cc3000 wiki page gives some details on how the process works,

1. The chip enters a smart config "listen" mode
2. Application on smart phone sends a "UDP" packet with access point settings
3. The chip captures this data and configures itself

I am aware of packet capture and wifi sniffing, but how does the chip "decrypt" the raw packet to get any info out of it ? I use wpa2-personal with AES on my router.

***********

As @Colin mentions the scheme that TI now use to communicate a network SSID and keyphrase from a setup application to a CC3000 enabled device is called Smart Config.

Smart Config has to communicate information (the network SSID and keyphrase) from a secure wifi network to a CC3000 enabled device that is not yet able to decrypt the traffic on that network.

Initially the CC3000 is not connected to the network (but can monitor the traffic), so the Smart Config application cannot send its information directly to the device. Instead it sends UDP packets to another existing machine on the network - the wifi access point (AP). That the AP isn't interested in receiving them is irrelevant, it's just important that the packets be visible on the network.

While the CC3000 can monitor the traffic it can't decrypt it, it can't even tell for certain that a given encrypted packet contains UDP data. So how can it pick out the UDP packets or do anything useful with them?

Basically Smart Config encodes its information not in the content of the packets it is sending but in their length. Wifi encryption affects the length of packets, but in a consistent way, i.e. it adds L additional bytes to the size of every packet, where L is a constant.

The Smart Config application encodes the SSID and keyphrase into the packet lengths of a sequence of UDP packets. The CC3000 can see the encrypted packets and their sizes.

In many environments the CC3000 will be able to see traffic from multiple nearby networks so how can it spot the relevant traffic? Even after encryption one can still see the MAC addresses of the source and destination of a packet so one can group traffic this way. In addition to the primary information that Smart Config is trying to send it also sends out regularly repeating patterns of packet lengths, so the CC3000 groups the traffic as described and then looks out for such patterns, when it finds them in the traffic of a given source and destination pair it then focuses in to recover the primary information.

There's obviously more too it than that, e.g. even once the CC3000 has found the source and destination pair, that correspond to the AP and the machine running the Smart Config application, how does it filter the Smart Config packets from other unrelated traffic going between the AP and the machine? I've written this all up in a series of blog posts.

The most technically detailed one covers the heart of Smart Config - how it encodes the SSID and keyphrase and transmits them such that a CC3000 can pick them up:

http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-transmitting-ssid.html

Then I have a post that's less technical, more an opinion piece about why you should always use an AES key with Smart Config:

http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-aes.html

There is a technical bit in the middle that does describe briefly how you'd configure a cipher in Java with the necessary AES transformation needed to work as the CC3000 expects.

And finally the proof of the pudding - I wrote an application to emulate the Smart Config related behavior of the CC3000, i.e. it can recover the SSID and keyphrase transmitted by any Smart Config application without needing to be able to decrypt the relevant network traffic. You can find where to download the source and all the details here:

http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-keyphrase.html

This should enable one to test the behavior of any Smart Config application one writes, i.e. one can see what a CC3000 would be able to reconstruct from the data transmitted by the application.

I also have a few more Smart Config / CC3000 related posts:

http://depletionregion.blogspot.ch/search/label/CC3000

For some background information it can also be interesting to read through these threads on the TI forum relevant to the CC3000.

First one covering Smart Config itself:

http://e2e.ti.com/support/low_power_rf/f/851/t/253463.aspx

And one on mDNS, the mechanism by which a Smart Config application detects that a CC3000 enabled device has joined the network:

http://e2e.ti.com/support/low_power_rf/f/851/p/290584/1020839.aspx

In both threads some initial messages may not seem so relevant but there's some interesting information mixed in too. But there's also a lot of inaccurate information as well so don't assume all of it is correct, even information from TI employees or from me (I learned a lot eventually but started with some incorrect assumptions/beliefs).

Patents have been mentioned a few times, however I can't find any evidence that there are patents pending or granted on this technology.