nRF5 SDK v17.1.0

The Secure Device Firmware Update (DFU) Service exposes necessary information to perform Device Firmware Updates on the device. This service is a proprietary service defined by Nordic Semiconductor to demonstrate a typical Device Firmware Update on an nRF5 device.

The UUID for the Secure DFU Service is 0xFE59. The service must be instantiated as a primary service.

The DFU Service does not depend on any other services. Support for the following GATT sub-procedures is mandatory for this service:

The DFU Service does not define any new error codes for the Attribute Protocol. Data exchange is in little endian (LSB first) order.

See DFU BLE Service for the API documentation.

Service characteristics

The following characteristics are mandatory:

Characteristic name Required properties Optional properties UUID
DFU Control Point Write, Notify 0x8EC90001-F315-4F60-9FB8-838830DAEA50
DFU Packet WriteWithoutResponse, Notify 0x8EC90002-F315-4F60-9FB8-838830DAEA50

The service does not impose any security requirements, which mean that encryption is not mandatory for any characteristics of the service. However, encryption should be used if available.

DFU Control Point

The UUID of the DFU Control Point characteristic is 0x0001.

The DFU Control Point characteristic is used to control the state of the DFU process. All DFU procedures are requested by writing to this characteristic. A response that marks the end of the procedure is received as a notification.

DFU Packet

The UUID of the DFU Packet characteristic is 0x0002. This characteristic receives data for Device Firmware Updates as DFU packets.

The maximum size of each packet is derived from the Att MTU size of the connection. The maximum Att MTU size of the DFU Service is 256 bytes (saved in NRF_SDH_BLE_GATT_MAX_MTU_SIZE), making the maximum size of the DFU Packet characteristic 253 bytes. (3 bytes are used for opcode and handle ID upon writing.) If no larger Att MTU size is negotiated with the DFU Service, the expected maximum size of a write is 20 Bytes. (BLE_GATT_ATT_MTU_DEFAULT minus the 3 bytes used for opcode and handle ID.) For simplicity, the Message sequence charts below show an example where no ATT MTU size was negotiated, so that a write of 20 byte is used.

Packets must be in little endian (LSB first) order.

Message sequence charts

The following message sequence charts show the transfer of an init packet and a firmware image, respectively.

Transfer of an init packet

The DFU controller first checks if the init packet has already been transferred successfully. If not, the DFU controller checks if it has been transferred partially. If some data has been transferred already, the transfer is continued. Otherwise, the DFU controller sends a Create command to create a new data object and then transfers the init packet. When the init packet is available, the DFU controller issues an Execute command to initiate the validation of the init packet.


Transfer of a firmware image

A firmware image is split up into several data objects that are transferred consecutively. If the transfer of a data object fails (for example, because of a power loss), the transfer can be continued instead of restarted. Therefore, the DFU controller starts by selecting the last data object that was sent and checks if it is complete and valid. If it is, the controller issues an Execute command and then continues the transfer with the next data object. Otherwise, the DFU controller sends a Create command to create a new data object if required (thus if the transfer for this data object has not started yet or the received data is corrupted) and then transfers the next data object.

When all packets are transferred, the DFU controller issues an Execute command to trigger the actual firmware update.

The DFU controller is responsible for keeping track of the progress. The response to each Select command contains information about the maximum object size, the current offset, and the CRC. For example, if the image size is 10 kB and the maximum object size is 4 kB, 3 data objects must be transferred. If the returned offset is 6 kB, the DFU controller knows that the current object is the second object to transfer and that is has not been transferred completely.


Data reliability

The BLE DFU Service is designed to handle serialized objects. However, transmitting and verifying serialized data is abstracted and not visible outside of the BLE transport layer.

To ensure that all data packets are received even though they are transmitted using WriteWithoutResponse, the DFU controller must perform a cyclic redundancy check (CRC) to validate the object before issuing an Execute command.

Documentation feedback | Developer Zone | Subscribe | Updated