 |
nRF51 SDK - S110 SoftDevice
|
|
nRF51 SDK - S110 SoftDevice
|
Example proprietary profile used to update firmware (application image) file using Bluetooth Low Energy. This is not a standard profile, and is defined by Nordic to demonstrate how a typical Device Firmware Update can be achieved.
The Device Firmware Update (DFU) Profile is used to transfer an application image from a BLE central (example, PC or Smart Phone) to a peripheral (example, Heart Rate Sensor) that supports Device Firmware Updates using the DFU Service.
The following is an overview of the main changes to the profile in order to support update of SoftDevice and Bootloader over BLE.
This profile requires the Generic Attribute Profile (GATT).
The profile defines two roles: DFU Target and Client. The DFU Target is the device which receives an image from the DFU Controller.
The following diagram shows the relationships between services and the two profile roles.
A DFU Target instantiates one instance of the DFU service.
The DFU Controller shall support the Device Firmware Update BLE Service.
| Service | DFU Controller |
|---|---|
| Device Firmware Update Service | M |
The DFU Controller shall also be tolerant when receiving the following ATT Error Code defined in CSS Part B, Section 1.2 of Supplement to the Bluetooth Core Specification, Version 3 or later:
The DFU Controller requests one of the procedures defined for Device Firmware Update using the DFU Control Point. Each procedure requested by the Controller is characterised by a request on the DFU Control Point, using the GATT Write Procedure. This may be followed by additional writes on the DFU packet characteristic based, followed by end of procedure marked by a response from the DFU Target for the procedure using GATT Notifications on the Control Point. Response code in the response packet determines the success or failure of the procedure. In case of failure, the response codes provide an indication on possible reason for failure. Refer to the detailed description for more details in the DFU Control Point. The DFU Target process one request at a time, therefore if a request is received on the Target when already processing one, an ATT Error Response with 'Procedure Already In Progress' is received on the DFU Controller. Asynchronous Status and Image Size received information are sent by the DFU Target as GATT Notifications on the control point.
Below is small MSC to show a typical DFU Control Point Procedure
DFU Procedures defined are listed below:
| DFU Procedure | Description |
|---|---|
| Start DFU | Procedure to prepare the device for a uploading the firmware. Size of firmware is provided in the request parameter. DFU Target response determines the device is ready for next stage of firmware update. The Start DFU must be followed by a byte indicating type of update, |
| Receive Init Data | Optional procedure to exchange information necessary for firmware update that needs to be exchanged before upload of firmware. Hash exchange / Public key exchange etc are some examples of such information. In case this optional step is omitted the validation phase consists only of size validation. |
| Receive App Data | Procedure to upload firmware fragmented as DFU Packets. Maximum size of each packet is (ATT_MTU - 3) octets. DFU Packets can be of variable length with a minimum size of 1 octet. |
| Validate | Procedure to validate updated firmware image. Current implementation supports only CRC, provided in "Receive Init Data" procedure, optional validation (size validation is done always) |
| Activate Image & Reset | Procedure to activate the new firmware and restart the device with new firmware. This procedure results in a GAP Disconnect. |
| System Reset | Procedure to reset system. This procedure result in a GAP Disconnection Procedure. |
| Report Received Image Size | Procedure to request the size of image received. |
| Packet Receipt Notification | Procedure to request notification on receiving every 'n' packets. The number 'n' is requested by the controller. This is not a mandatory procedure for the Controller. |
DFU Target in DFU mode, is in GAP General Discoverable mode and is connectable. 128-bit DFU Service UUID is advertised in the Advertisement Data, along with full name of DfuTarg.
Once connected to the DFU Controller, DFU Procedure can be started by requesting a Start DFU Procedure. Size of new firmware is provided during this procedure. On successful Start DFU procedure, Receive Init Data is initiated to exchange CRC information. On success, this procedure is followed by upload of new firmware by requesting the Receive App Data Procedure. Currently, banked update is performed, implying, the old firmware can be restored in case firmware update procedure did not succeed at any stage of DFU Transfer. New firmware transferred is validated using the Validate Procedure. Validated firmware can be activated by issuing the Activate Image & Reset Procedure. It is possible to reset the system at any stage using the System Reset procedure. When this procedure is requested, the system will restart with old firmware in case the device had a firmware; in case the device did not have any existing application firmware the system will restart in DFU mode.
Firmware being updated is expected in binary format. It is possible to request the size of received firmware by requesting the Report Received Image Size procedure. This procedure is particularly useful on reconnection after a link loss. See Link Loss Procedure for more details. It is also possible for the Controller to request notification of acknowledge for every 'n' packets received using the Packet Receipt Notification procedure.
MSC below describes a typical firmware update exchange between a DFU Controller and DFU Target.
In case no connection is established with the DFU Target after 60 seconds, Target device will restart in normal mode with old firmware, in case there was an existing application, else in DFU mode, in case there was no application on the device.
Procedure validates the updated firmware image. Current Nordic implementation supports only CRC, provided in "Receive Init Data" procedure, optional validation additionally to size validation which is always performed.
When the Nordic bootloader application detects that the connection has been idle for a time period, meaning that the DFU Controller has not written any packet that will result in the progress of the firmware update, the update will be stopped, the connection will be terminated, and the previously valid application will be started. If no valid application exists in the flash, the application stays in bootloader mode waiting for a reconnection from the DFU Controller.
When the Nordic bootloader application detects a link loss, DFU state and image size is remembered. On reconnection to the Controller, the transfer can resume from where it had stopped. Controller can request size of received image using the Report Received Image Size Procedure and start transfer by applying the necessary offset. Idle Mode Procedures apply in the disconnected state on link loss.
This feature allows the DFU Controller to subscribe for a notification from the DFU Target, each time a given number of firmware packets is received by the latter. To use this feature, the DFU Controller should write to the DFU Control Point, the Op Code 0x08 - Packet Receipt Notification Request followed by the Number of packets. If the Number of packets field is set to N, then the DFU Target will send a Notification of the DFU Control Point with Op Code = 0x11 - Packet Receipt Notification, each time it receives N number of firmware packets. The DFU Controller should wait for this notification each time it has finished sending N number of firmware packets.
In Packet Receipt Notification, the DFU Target also sends the number of bytes of firmware data received until that point of time. This may be used for any consistency checks by the DFU Controller.
This section describes the security considerations for a DFU Target and DFU Controller.
All supported characteristics specified by the DFU Service are set to Security Mode 1 and Security Level 1.
Nordic Device Firmware Update (DFU) Service exposes necessary information to perform Device Firmware Update on the device. NOTE: This is not a service defined by the Bluetooth SIG, a proprietary one to demonstrate a typical firmware update on an nRF51 device.
DFU Service does not depend on any other service. Support for following GATT sub-procedures are mandatory for this service: a. Write Characteristic Value b. Notifications c. Read Characteristic Descriptors d. Write Characteristic Descriptors
DFU GATT Service can operate on Bluetooth Low Energy as transport only.
The Service does not define any new error codes for Attribute Protocol and data exchange in is little endian (LSB first) order.
This service is instantiated as a primary service in the DFU mode.
The Service UUID assigned is value 0x1531 over proprietary base, see table below.
UUID For Nordic:
| Description | Number Base |
|---|---|
| Company Identifier: | 0x0059 |
| UUID Base: | 0x23, 0xD1, 0xBC, 0xEA, 0x5F, 0x78, 0x23, 0x15, 0xDE, 0xEF, 0x12, 0x12, 0x00, 0x00, 0x00, 0x00 |
| Service UUID start: | 0x1530 |
| Characteristic UUID start: | 0x1531 |
DFU Service exposes one instance of characteristics listed in table below. This service does not impose any security requirements.
| Characteristic Name | Requirement | Mandatory Properties | Descriptors | Description |
|---|---|---|---|---|
| DFU Packet | M | WriteWithoutResponse | See DFU Packet | |
| DFU Control Point | M | Write, Notify | See DFU Control Point |
This characteristic receives firmware to nRF51 device as DFU Packets. The firmware is transferred by writing each fragment as DFU Packet to this characteristic. Size of each packet is in range of 1 to (ATT_MTU - 3).
All DFU Procedures are requested using this characteristic. A DFU Procedure request is initiated by writing to this characteristic. A Response, marking end of procedure is received as a notification. The Characteristic value or the DFU Control PDU has the following format
The DFU Control Point characteristic is used to control the state of Device Firmware Update process.
Table below summarizes control point procedure op-code and respective parameters.
If an Op Code is written to the DFU Control Point characteristic and the Client Characteristic Configuration descriptors of either or both of the DFU Control Point or the DFU Status Report are not configured for notifications, the DFU Target will return an error response with the Attribute Protocol Application error code set to Client Characteristic Configuration Descriptor Improperly Configured as defined in CSS Part B, Section 1.2 of Supplement to the Bluetooth Core Specification, Version 3 or later.
1.8.3.1 
