Understanding the message sequence chart for doing a firmware update

[jerome.sc]

I'm looking at using a custom phone application to do a firmware update on my nRF52833. I'm not using the library from Nordic, as it is written in a different language then what the rest of the application is in.

I was looking at the message sequence chart, from the link below. I'm confused on some of the information it shows.

• Is the 60 part in the response from the control point always part of each response? For example, what is shown in the screenshot below:
  

• When using the commands, the first parameter says what command it is e.g. 06 is select, 03 is crc, etc. What does the second parameter mean? For example, in the transfer of an init packet, 06 01 is the select command, but in the Transfer of a firmware image, 06 02 is the select command. I'm unsure on what the difference between the 01 and 02 is in the two commands.
• With the response e.g. Response Create Success [60 01 01], I assume 60 is the default response, 01 is the response to for example the create command. But what does the second 01 mean? I assume it means 01 for success or anything else for an error.

• It seems like the message sequence charts for v17.0.2 is missing information, in comparison to v15.3.0. v15.3.0 mentions setting the PRN and getting the MTU size, and says that this needs to be done before the init packet is sent. The MTU size seems to come from my code, so just sending the command [07] should get the size, but what does the response [60 07 01 01] mean? 60 is the default, 02 for MTU command, 01 for success, but what does the other 01 mean?
• With the PRN, how does sending [02 00 01] set it to the PRN to 256?
  

17.0.2 Message Sequence Chart

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Flib_dfu_transport_ble.html

15.3.0 Message Sequence Chart
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.3.0%2Flib_dfu_transport_serial.html&cp=5_1_3_5_2_3_1_0&anchor=lib_dfu_serial_transport_msc_init

[Einar Thorsrud]

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

[jerome.sc]

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?

[Einar Thorsrud]

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.

[jerome.sc]

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

[Einar Thorsrud]

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.

[jerome.sc]

Ok, thank you.