This an example of a bootloader with Device Firmware Update, DFU, capabilities. This example contains support for SoftDevice and Bootloader update in addition to Application update found in the normal Bootloader/DFU example, Bootloader/DFU Introduction.

Here is an overview of the Bootloader/DFU with SoftDevice update example for the nRF51822 Chip. Device firmware update is envisaged to be performed on a device to
    a. Update SoftDevice to newer version. Current SoftDevice must be v.7.0.0-alpha or later.
    b. Update SoftDevice and Bootloader/DFU to newer versions in a single update process. Current SoftDevice must be v.7.0.0-alpha or later.
    c. Update Bootloader to newer version. Current SoftDevice must be v.7.0.0-alpha or later.
    d. Update Application with/without an existing Application on device.

Note: The Bootloader/DFU is only supported on nRF51822 devices with 256 kB flash.

In case the device has an existing application image when performing a SoftDevice update then the application will be erased. In order to ensure enough resources for a SoftDevice update then the flash area between end of SoftDevice and beginning of the Bootloader will be used for storage of the new SoftDevice image and Bootloader (optional).

Transfering of Bootloader/DFU or Application will use the 'dual-bank' transfer mode where the current image is preserved until a succesful transfer and validation of the new image has completed. See also Memory layout to understand flash access operations better.

Current example support Bluetooth Low Energy as transport. For more details see Bootloader/DFU Architecture with SoftDevice update. The DFU example itself is designed to be transport agnostic. DFU application interface is detailed in Bootloader/DFU API. This examples defines 'control' messages for initiating DFU procedures like Start DFU, Stop DFU, Reset the System, Activate New Image & Reset Device etc. A comprehensive list of the procedures identified along with format each message is detailed in the exp_dfu_bootloader_api section. The firmware itself, being larger than maximum Data Unit of the transport being used, can be transmitted as smaller fragments that fit into the transport Data Unit. Each of such fragment is referred to as a DFU Packet. Current DFU Packet is simple, and does not contain an individual CRC fields. However, an overall CRC check on firmware is provisioned for. The image is expected in binary format.

For more detailed description of the example, please refer to the following sub-pages.

Section	Description
Introduction to Bootloader/DFU	Introduction to the Bootloader/DFU with SoftDevice update example project (This page)
Bootloader/DFU Architecture	Architectual view of the Bootloader/DFU Solution
Bootloader/DFU Keil Project	Description of the Keil project, compiling Bootloader/DFU, and software flash download (nrfjprog)
DFU BLE Transport Layer	DFU BLE Transport Layer description
Flash Memory Layout	Detailed description of the flash memory layout for SoftDevice, application, and bootloader/DFU
Bootloader/DFU API	API description for modules specific for the Bootloader/DFU Example

Introduction to Bootloader/DFU

The DFU Bootloader is capable of receiving a SoftDevice, Bootloader/DFU and Application image on the BLE and updating the current running SoftDevice, Bootloader/DFU or Application on the nRF51822 Chip. The source code and project file for nRF51822 can be found
<InstallFolder>\Nordic\nrf51822\Board\nrf6310\experimental\device_firmware_updates\bootloader

If there is no existing application in the nRF device, the device will be started in the bootloader mode. In case the device has an existing application, it will need to be put explicitly in the bootloader mode using button 7.

Experimental, sample PC application to perform device firmware update for nRF51822 have been provided at
<InstallFolder>\Nordic\nrf51822\Board\nrf6310\experimental\device_firmware_updates\ble_dfu_send_hex

location. The readme.txt that accompany this sample application provide instructions on how to use them. It is important to note that the sample application accept firmware in hex formats and internally convert them to binary format. The device itself, expects the firmware in binary format and not hex.

The PC application will automatically detect if the hex file is containing a. SoftDevice b. SoftDevice with Bootloader c. Bootloader d. Application

The board setup used for the DFU Bootloader can be found at nRFgo Motherboard Setup (nRF6310). The DFU Bootloader example will work both with or without the display module.

Architectural Overview

The firmware update process has been modelled as an event driven state machine. With each event signifying a specific DFU Procedure. The events and procedures are transport agnostic, hence it is possible to to perform a firmware update on any transport. State diagram and events are described in Bootloader/DFU Architecture. Peer or the uploading device can trigger/drive the events by sending a corresponding message on the DFU transport. List of all defined messages can be found at DFU Event Message Types.

The procedures and state machine is identical for single and dual bank transfers. However, each transport may differ in the way the actual message is transferred, for this, please refer to transport specific pages. For example, for Bluetooth Low Energy all control messages are requested by writing to Control Characteristic. However, in serial, no logical data points are created for control or data messages. It should also be noted that no sequence numbers or DFU Packet loss mechanisms have been added for optimized exchange, DFU assumes a reliable transport. Therefore, it is left to the transport or transport-DFU shim to ensure reliable data transfer. It is also responsibility of the transport to submit the DFU packets in the right order and one at a time. DFU does not handle out-of-order DFU packets.

Bootloader/DFU API

DFU interfaces with the transport using the Application Interface (API), each API signifies a sub procedure request. It should be noted that the APIs itself are designed to be non-blocking, but, the CPU is halted on flash operations, hence operations that result in flash access given the impression of a blocking API. Please refer to the section on Non Volatile Memory Controller in nRF Reference Manual for more details on impact of flash access. It is recommended that the flash access times are well understood when expecting a response/acknowledgement for a message on any transport.

For detailed description of APIs and DFU procedures, please refer Bootloader/DFU API section.

Bootloader/DFU User Interface

Instructions on how to set up the nRFgo Motherboard: nRFgo Motherboard Setup (nRF6310).

LED assignments:

LED 0: Advertising
LED 1: Connected
LED 2: Bootloader Mode Active
LED 7: Asserted (i.e. an assert check in the application has failed)

Button assignments:

Button 7: Enter Bootloader Mode

Testing

Updating Applications

Before testing the Bootloader/DFU example, erase the device and program the SoftDevice. Have two compiled and linked application HEX files ready for the update procedure. The Bootloader/DFU example can be tested using the Master Control Panel (MCP) as follows:

Compile and program the application. Observe that the Bootloader Mode Active and the Advertising LED is lit.
Select to the device from MCP, the device will be advertising as 'DfuTarg'. Connect and perform service discovery. Observe that the Connected LED is lit, and the Advertising LED is off.
MCP automatically recognizes that the device supports Device Firmware Update, and the 'DFU' button becomes available on the application's user interface.
Click the 'DFU' button and pick a compiled and linked application HEX file. After clicking 'Open', observe that the update procedure starts and wait until the progress bar reaches 100%. The new application is started automatically, observe that the Advertising LED is lit.
In MCP go back to device discovery and observe the device advertising with the updated firmware.
To perform another update, reset the device while holding down the Enter Bootloader Mode button. Observe that the Bootloader Mode Active and the Advertising LED is lit.
Repeat steps 2-4.

Updating the SoftDevice, the Bootloader, or both

The Master Control Panel application currently does not support SoftDevice/Bootloader update. For testing these features please refer to the following document: <InstallFolder>\Nordic\nrf51822\Board\nrf6310\experimental\device_firmware_updates\ble_dfu_send_hex\readme.txt

Troubleshooting

This section covers some known issues and their solution for the Bootloader/DFU project

Error	Solution
linking... ._build\bootloader.axf: Error: L6406E: No space in execution regions with .ANY selector matching .....	This error message will be seen if the Bootloader/DFU image does not fit into the Size specified in the project setting, try using higher optimization level, -O3, or increase the Bootloader/DFU code area as described in Bootloader/DFU compile targets
No Algorithm found for: 10001014H - 10001017H Partial Erase Done (areas with no algorithms skipped!) No Algorithm found for: 10001014H - 10001017H	Those error messages are seen when trying to flash with the J-Link Target Driver, as it does not support writing of UICR. Use `nrfjprog.exe` instead.
Bootloader/DFU project suddenly stopped working after changing Bootloader/DFU Start address and re-flashing	After changing the Bootloader/DFU Start address, the nRF51822 Chip should be erased and re-programmed with the SoftDevice and then with the Bootloader/DFU.
— Error: failed to execute '"nrfjprog.exe" .....	nrfjprog.exe could not be found in windows path. Add nrfjprog.exe to windows %PATH% or specify full path to nrfjprog in Keil-'Options for Target'-'Utilities' as seen in Figure 3.
Uploaded application does not run	Verify that the application has been compiled with the correct start address. For S110 SoftDevice this would be Address `0x00016000` and for S310 SoftDevice it would be `0x00020000`.