Understanding the message sequence chart for doing a firmware update

RE: Understanding the message sequence chart for doing a firmware update

jerome.sc — Thu, 06 Jul 2023 09:37:36 GMT

Ok, thank you.

RE: Understanding the message sequence chart for doing a firmware update

Einar Thorsrud — Thu, 06 Jul 2023 08:34:35 GMT

The documentation is a bit unclear. Execute should be called for every object, but behaves differently depending on the state. I suggest taking a look at the implementation in the old nrfutil (mostly in dfu_transport_ble.py) for a working reference implementation.

RE: Understanding the message sequence chart for doing a firmware update

jerome.sc — Tue, 04 Jul 2023 09:00:31 GMT

Ok, that makes sense.

I have one last question to do with the message sequence chart, about transferring a firmware image. Does the execute command happen only once (i.e. when the full firmware image has been sent), or multiple times, as from the chart it looks like it's called within the repeat statement.

I'm confused because of the line about the chart saying "When all packets are transferred, the DFU controller issues an Execute command to trigger the actual firmware update."

RE: Understanding the message sequence chart for doing a firmware update

Einar Thorsrud — Tue, 04 Jul 2023 08:42:55 GMT

Hi,

Yes, packets can be larger. In BLE, you can have larger physical packets (with data length extension), and also larger packets at the ATT layer (given by the ATT MTU), and this can span several physical packets. The GATT MTU size refer to the GATT layer, which can be up to 512 bytes.

Regarding the MTU get command that has no use in BLE (as this is not handled by the DFU protocol in this case), but it is used for other transports, specifically serial (UART) and ANT. As MTU is handled on the Bluetooth layer, you will need to use the Bluetooth APIs on iOS/Android (if that is the platform for your app) to operate on that.

RE: Understanding the message sequence chart for doing a firmware update

jerome.sc — Tue, 04 Jul 2023 08:32:15 GMT

I'm a bit confused about the last point. When doing a firmware update over BLE, can the packets being sent be bigger than the standard 20 bytes? If so is that from setting it in the code NRF_SDH_BLE_GATT_MAX_MTU_SIZE, and using the MTU get MTU command [07], to see what the size is set to?

RE: Understanding the message sequence chart for doing a firmware update

Einar Thorsrud — Tue, 04 Jul 2023 08:16:55 GMT

Hi,

The response always contain the response code (0x60), the op code and the result (in that order). So [60 01 01] means that it is a response to create (0x01) and the result is 0x01 (success). You can refer to nrf_dfu_result_t for a list of result codes.

Regarding the other questions, there are two key points that should help to explain most of them. First of all, the every request has a format and set of parameters defined in this table. And when looking at the data, you need to be aware that this is little endian. This is for instance why [02 00 01] sets RPN to 256, as 0x0100 is 256.

Lastly, MTU that is handled ad the BLE level and not in the DFU protocol itself when using Bluetooth as transport. When using UART, it is handled in the DFU protocol, as there is no ;MTU concept in UART. (You can see that MTU is done at Bluetooth level if you search for MTU in components\libraries\bootloader\ble_dfu\nrf_dfu_ble.c).

Einar