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 or later.
    b. Update SoftDevice and Bootloader/DFU to newer versions in a single update process. Current SoftDevice must be v.7.0.0 or later.
    c. Update Bootloader to newer version. Current SoftDevice must be v.7.0.0 or later.
    d. Update Application with/without an existing Application on device.

Note: Support for SoftDevice and Bootloader update is only supported on nRF51822 devices with 256 kB flash. Application update is supported on both 128 kB and 256 kB chip variants.

Warning: If the register UICR.CLENR0 has a size value, e.g. 0x00016000 then it will not be possible to update to a SoftDevice of larger size.

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 supports Bluetooth Low Energy or HCI/UART as transport layers. 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 Bootloader/DFU 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
DFU Transport Layers	Detailed description of BLE and HCI/UART Transports layers
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.

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.

Two experimental sample PC applications to perform device firmware update for nRF51822 are provided:

<InstallFolder>\Nordic\nrf51\examples\dfu\ble_dfu_send_hex
<InstallFolder>\Nordic\nrf51\examples\dfu\hci_dfu_send_hex

The readme.txt files that accompany these sample applications provide instructions on how to use them. It is important to note that the sample applications 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:

SoftDevice
SoftDevice with Bootloader
Bootloader
Application

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 with SoftDevice update. 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

The names for the example are dfu_dual_bank_ble_pca10028, dfu_single_bank_ble_pca10028, and dfu_dual_bank_serial_pca10028. If you are not using Keil to work with the SDK, you can find the source code and project file of the example in the following folder: <InstallFolder>\Nordic\nrf51\examples\dfu\bootloader

LED assignments:

LED 1: Advertising
LED 2: Connected
LED 3: Bootloader Mode Active

Button assignments:

Button 4: Enter Bootloader Mode

Testing

Master Control Panel, v.3.7.1

Master Control Panel, Version 3.7.1 and earlier are not supporting the DFU Init packet, Init packet handling. This SDK contains an updated version version of the ble_dfu.py python script which works stand-alone or together with MCP, v3.7.1.

To update MCP to support the new Init packet it is necessary to change the ble_dfu.py script provided in MCP with the SDK version.

To do so, copy the files found in <InstallFolder>\Nordic\nrf51\examples\dfu\ble_dfu_send_hex\dfu

<InstallFolder> will be the path to the Pack folder within Keil if packs are used, or the location where the zip file was extracted.
Overwrite the files used by MCP which is found in: "c:\Program Files (x86)\Nordic Semiconductor\Master Control Panel\3.7.1.8567\lib\dfu\"

Note: The files must be copied as administrator in Windows.

Updating SoftDevice, Bootloader and Applications using IronPython script

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.

Test the Bootloader/DFU Example with the Master Control Panel by performing the following steps:

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, bootloader or SoftDevice HEX file.
Choose the type of Hex file that has been selected.
Press 'Program', observe that the update procedure starts and wait until the progress bar reaches 100%.
- If an application was transfered then it is started automatically, observe that the Advertising LED is lit.
- If Bootloader or SoftDevice was transfered, the system will restart in DFU mode.
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-6.

Updating SoftDevice, Bootloader and Applications using IronPython script

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.

Test the Bootloader/DFU Example with the Master Control Panel by performing the following steps:

Compile and program the application. Observe that the Bootloader Mode Active and the Advertising LED is lit.
Execute the DFU Update script from Command line:
- "ipy main.py --file <image_file.hex> --mode <mode> --address <target address>"
- where:
- "<image_file.hex>" can be any application, softdevice, or bootloader image, subject to restrictions described in notes below.
- "<target address>" is the address of the device advertising 'DfuTarg'.
- "<mode>" is one of the valid image types to transfer: Application, Softdevice, Bootloader, SdAndBl
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.

For additional details on command line update, please look at the readme.txt found in <InstallFolder>\Nordic\nrf51\examples\dfu\ble_dfu_send_hex.

Using Serial Transport Layer

For testing the Bootloader/DFU example using the Serial Transport Layer, a 32-bit windows application is provided. See the readme.txt file of the hci_dfu_send_hex_pca10028 example for instructions on how to use the sample application.

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`.