End DFU mesh

[Tomi]

Hi!

For our development purposes I am implementing NRFUTIL 0.3 for mesh on Android/Java, migrating it from Python code, via UART/Serial, for DFU purposes

It looks like the code is half finished on some parts and I am wondering if this works as it should

1. When send_firmware is finished, how do you properly end DFU?
IF I check the code, after the firmware is done sending, it is calling

self.dfu_transport.send_validate_firmware()

and

self.dfu_transport.send_activate_firmware()

But this 2 code functions for mesh just return "True" or pass and don't do anything?

When I send firmware partially or if I send it 100% I always get response like:
A3 02 04 59 00 00 00 01 00 03 00 00 00 06

and that is it. So A3 = DFU End

1.1 So is that it? Will all devices (with device updating mesh) be updated, or do I need to call something else, like sending bank flash command?
1.2 And what happens if firmware progress was not 100% finished? Can I just start DFU again and send remaining data or do I need to start whole process again?

2. There are some functions called from _handle_dfu:

def _handle_dfu(self, data):
    handle = bytes_to_int32(data[:2])
    if handle is MESH_DFU_PACKET_FWID:
        self._handle_dfu_fwid(data[2:])
    elif handle is MESH_DFU_PACKET_STATE:
        self._handle_dfu_state(data[2:])
    elif handle is MESH_DFU_PACKET_DATA_REQ:
        self._handle_dfu_data_req(data[2:])

But this never gets called, because I am getting 0x84 response all the time, when sending firmware, which is only ACK

2.1 Am I maybe missing something, or I have not implemented it correctly or is this not needed?

3. How can I request scanning response for all bluetooth devices visible? Because I can see there is some Provisioned devices scan, which I haven't been able to make it work yet, but can I get result via UART for visible devices and some of their info?

I got this working. I send 0x61 and I get all unprovisioned devices via serial port, so that works! 

Thank you in advance!

[Hung Bui]

Hi, 

I assume you solved question #3 and still want to ask about #1, and #2. 

Regarding 1.1: Actually send_validate_firmware and send_activate_firmware is not relevant to mesh dfu. We have that in the code so that the APIs compatible with the generic DFU class (BLE/serial) . So no worries about them. Mesh node has to detect when the image is received fully and start activation automatically. 

I will check with the developer regarding your other questions and get back to you. 

[Tomi]

Yes I kinda solved question #3
Ok thank you!

Regarding 1.1
When DFU is complete, can I retrieve some info on my mesh if nodes were updated successfully or is this something that would need to be implemented on each node when they update? Or if Its there a way to check mesh devices firmware version?
Because I would like to know if everything went as is should, so I know status of mesh devices and their firmware version and what to do next if something fails here

Regarding this, when you get DFU complete (already written above), from serial BT device
A3 02 04 59 00 00 00 01 00 03 00 00 00 06

This returns byte 03, firmware version, but in this case firmware was not completed successfully, so provisioner device returns version of uncompleted transfer? 

[Hung Bui]

Hi,

I just checked with our Mesh team, regarding your questions, I quote here his response:

"The packet you posted is 0xA3 “dfu end”. The last byte is the end reason (from nrf_mesh_dfu_end_t), and 6 means timeout. The timeout occurs when the device doesn’t get any packets for N number of seconds, which means that it abruptly lost contact with the sender. It is the typical end reason for poor connections, but should never occur in the serial-device if it and the serial script is properly configured.

 They’ll get dfu end with reason 0x00 “success” if everything went according to plan, but this only applies when running in background mode. After the transfer finishes, the device will start sending out firmware ID beacons indicating the current version. This can be used to determine whether the transfer was successful, but it doesn’t tell you anything about why the previous transfer failed, or if it did. "

So basically you don't have the response except for the Firmware ID beacons after the DFU finishes.