Lines Matching full:firmware
3 Device Firmware Update (DFU)
6 Bluetooth Mesh supports the distribution of firmware images across a mesh network. The Bluetooth
7 mesh DFU subsystem implements the Bluetooth Mesh Device Firmware Update Model specification version
10 Bluetooth Mesh DFU implements a distribution mechanism for firmware images, and does not put any
13 firmware validation and deployment to the application.
32 distribution of firmware images:
35 Target node is the receiver and user of the transferred firmware images. All its functionality is
41 node in the Upload Firmware procedure, then it distributes the uploaded image to other Target
53 Target nodes and their firmware, and will control (and initiate) all firmware updates. The
69 replace the Firmware Distribution Server model with a proprietary mechanism that will access the
70 Firmware Update Client model directly, e.g. over a serial protocol.
83 phone or gateway (the Initiator). During the Upload stage, the Initiator transfers the firmware
85 stores the firmware image and its metadata persistently, and awaits further instructions from the
88 time-consuming Distribution stage. Once the firmware has been uploaded to the Distributor, the
91 Firmware Capability Check stage (optional)
93 accept the new firmware. Nodes that do not respond, or respond that they can't receive the new
94 firmware, are excluded from the firmware distribution process.
97 Before the firmware image can be distributed, the Initiator transfers the list of Target nodes
98 and their designated firmware image index to the Distributor. Next, it tells the Distributor to
99 start the firmware distributon process, which runs in the background while the Initiator and the
100 mesh network perform other duties. Once the firmware image has been transferred to the Target
101 nodes, the Distributor may ask them to apply the firmware image immediately and report back with
102 their status and new firmware IDs.
104 Firmware images
107 All updatable parts of a mesh node's firmware should be represented as a firmware image. Each Target
108 node holds a list of firmware images, each of which should be independently updatable and
111 Firmware images are represented as a BLOB (the firmware itself) with the following additional
114 Firmware ID
115 The firmware ID is used to identify a firmware image. The Initiator node may ask the Target nodes
116 for a list of its current firmware IDs to determine whether a newer version of the firmware is
117 available. The format of the firmware ID is vendor specific, but generally, it should include
119 image as well as its version. The firmware ID is optional, and its max length is determined by
122 Firmware metadata
123 The firmware metadata is used by the Target node to determine whether it should accept an
124 incoming firmware update, and what the effect of the update would be. The metadata format is
129 determine whether the transfer should be started. The firmware metadata can be discarded by the
131 Target node. The firmware metadata is optional, and its maximum length is determined by
143 | New firmware version | 8 B | 1 B: Major version |
148 | New firmware size | 3 B | Size in bytes for a new firmware |
150 | New firmware core type | 1 B | Bit field: |
159 | | | in the New firmware core type field. |
162 | | (Optional) | after firmware is applied. |
164 | | | in the New firmware core type field. |
167 | data for new firmware | (Optional) | application to execute some |
179 Firmware URI
180 The firmware URI gives the Initiator information about where firmware updates for the image can
182 versions of the firmware. This allows Initiators to perform updates for any node in the mesh
185 according to the Firmware Check Over HTTPS procedure defined by the specification. The firmware
195 Firmware effect
201 the device may either boot up unprovisioned after applying the new firmware or require to be
205 The device stays provisioned after the new firmware is programmed. This effect is chosen if the
206 composition data of the new firmware doesn't change.
215 This effect is chosen if the composition data in the new firmware changes, the device doesn't
217 firmware.
219 When the Target node receives the Firmware Update Firmware Metadata Check message, the Firmware
225 firmware image. See :ref:`bluetooth_mesh_dfu_srv_comp_data_and_models_metadata` for more
247 Uploading the firmware
250 The Upload Firmware procedure uses the :ref:`bluetooth_mesh_blob` to transfer the firmware image
251 from the Initiator to the Distributor. The Upload Firmware procedure works in two steps:
253 1. The Initiator generates a BLOB ID, and sends it to the Distributor's Firmware Distribution Server
254 along with the firmware information and other input parameters of the BLOB transfer. The Firmware
257 #. The Initiator's BLOB Transfer Client model transfers the firmware image to the Distributor's BLOB
260 When the BLOB transfer finishes, the firmware image is ready for distribution. The Initiator may
261 upload several firmware images to the Distributor, and ask it to distribute them in any order or at
262 any time. Additional procedures are available for querying and deleting firmware images from the
265 The following Distributor's capabilities related to firmware images can be configured using the
275 Before the Distributor can start distributing the firmware image, it needs a list of Target nodes to
278 populate the Distributor's receivers list with the address and relevant firmware image index of each
279 Target node. The Initiator may send one or more Firmware Distribution Receivers Add messages to
280 build the Distributor's receivers list, and a Firmware Distribution Receivers Delete All message to
289 Once the Distributor has stored a firmware image and received a list of Target nodes, the Initiator
292 Distributor should request that the firmware is applied on the Target nodes or not. The Distributor
293 stores the transfer parameters and starts distributing the firmware image to its list of Target
296 Firmware distribution
299 The Distributor's Firmware Update Client model uses its BLOB Transfer Client model's broadcast
300 subsystem to communicate with all Target nodes. The firmware distribution is performed with the
303 1. The Distributor's Firmware Update Client model generates a BLOB ID and sends it to each Target
304 node's Firmware Update Server model, along with the other BLOB transfer parameters, the Target
305 node firmware image index and the firmware image metadata. Each Target node performs a metadata
307 response to the Firmware Update Client, indicating if the firmware update will have any effect on
309 #. The Distributor's BLOB Transfer Client model transfers the firmware image to all Target nodes.
310 #. Once the BLOB transfer has been received, the Target nodes' applications verify that the firmware
313 #. The Distributor's Firmware Update Client model queries all Target nodes to ensure that they've
314 all verified the firmware image.
320 The firmware distribution procedure only fails if *all* Target nodes are lost. It is up to the
327 The Initiator can also request the Distributor to suspend the firmware distribution. In this case,
328 the Distributor will stop sending any messages to Target nodes. When the firmware distribution is
329 resumed, the Distributor will continue sending the firmware from the last successfully transferred
332 Applying the firmware image
335 If the Initiator requested it, the Distributor can initiate the Apply Firmware on Target Node
336 procedure on all Target nodes that successfully received and verified the firmware image. The Apply
337 Firmware on Target Node procedure takes no parameters, and to avoid ambiguity, it should be
338 performed before a new transfer is initiated. The Apply Firmware on Target Node procedure consists
341 1. The Distributor's Firmware Update Client model instructs all Target nodes that have verified the
342 firmware image to apply it. The Target nodes' Firmware Update Server models respond with a status
346 #. The Target node's application swaps the current firmware with the new image and updates its
347 firmware image list with the new firmware ID.
348 #. The Distributor's Firmware Update Client model requests the full list of firmware images from
349 each Target node, and scans through the list to make sure that the new firmware ID has replaced
354 it will become unprovisioned after the firmware image is applied. In this case, the Distributor's
355 Firmware Update Client model will send a request for the full firmware image list, and expect no
361 The firmware distribution can be cancelled at any time by the Initiator. In this case, the
365 procedure can be started again from the ``Firmware distribution`` section.
371 This section lists the types common to the Device Firmware Update mesh models.