FOTA
We've got over-the-air firmware updates (FOTA) working for the platforms based
on Nordic's nRF51822<<@pratul: LINK NEEDED>>. This means that it is possible to update
the firmware of a 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.
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<<@pratul LINK>>, 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/.
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
/* 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.
UART access over BLE
If you want to receive console output from an updated app, it is possible to
do so over the BLE UART Service. For instance, the default app which comes
bundled with the bootloader generates regular pings on the rx-characteristic
of the UARTService. These pings can be received using one of several UART
apps, such as Nordic's
nRF
UART.
Please be aware that presently it is possible to have only a single active
connection to a BLE device; so let's say you're working with a heart-rate
application and if you've connected to it using nRF UART for console output,
then you cannot simultaneously connect to it from another heart-rate phone
app.
Please also note that console messages are sent across in notification packets
of up to 20 bytes in size; this limit is imposed by Bluetooth standard. So
longer messages need to be cropped into a sequence of 20-byte packets. Output
buffers internal to the UARTService are flushed upon encountering a newline
character. The receiving UART application should be able to stitch together
cropped portions of longer messages.
Using the UART service
The following program illustrates the use of UARTService to redirect something
like printf() to use the BLE transport.
code changes needed to redirect console output to UART Service
#if NEED_CONSOLE_OUTPUT
#define DEBUG(STR) { if (uart) uart->write(STR, strlen(STR)); }
#else
#define DEBUG(...) /* nothing */
#endif /* #if NEED_CONSOLE_OUTPUT */
uart = new UARTService(ble);
DEBUG("ping\r\n");
You will also need to include UARTService.h.
Limitations of our current implementation
- 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.
Nilesh Bhavsar.
42
replies
Rohit Grover wrote: 
Warning
There is a newer version of this information on The BLE Team wiki FOTA page
FOTA
We've got over-the-air firmware updates (FOTA) working for the platforms based on Nordic's nRF51822<<@pratul: LINK NEEDED>>. This means that it is possible to update the firmware of a 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.
Components Involved
The following image shows the layout of the main software components which go into a FOTA capable system. These include:
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<<@pratul LINK>>, 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/.
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
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.
UART access over BLE
If you want to receive console output from an updated app, it is possible to do so over the BLE UART Service. For instance, the default app which comes bundled with the bootloader generates regular pings on the rx-characteristic of the UARTService. These pings can be received using one of several UART apps, such as Nordic's nRF UART.
Please be aware that presently it is possible to have only a single active connection to a BLE device; so let's say you're working with a heart-rate application and if you've connected to it using nRF UART for console output, then you cannot simultaneously connect to it from another heart-rate phone app.
Please also note that console messages are sent across in notification packets of up to 20 bytes in size; this limit is imposed by Bluetooth standard. So longer messages need to be cropped into a sequence of 20-byte packets. Output buffers internal to the UARTService are flushed upon encountering a newline character. The receiving UART application should be able to stitch together cropped portions of longer messages.
Using the UART service
The following program illustrates the use of UARTService to redirect something like printf() to use the BLE transport.
Import programBLE_UARTConsole
A console service.
Last commit 29 Sep 2015 by
Bluetooth Low Energy
code changes needed to redirect console output to UART Service
#if NEED_CONSOLE_OUTPUT #define DEBUG(STR) { if (uart) uart->write(STR, strlen(STR)); } #else #define DEBUG(...) /* nothing */ #endif /* #if NEED_CONSOLE_OUTPUT */ uart = new UARTService(ble); DEBUG("ping\r\n");You will also need to include
UARTService.h.Limitations of our current implementation