End DFU mesh

RE: End DFU mesh

Hung Bui — Wed, 23 Jan 2019 14:03:57 GMT

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.

RE: End DFU mesh

Tomi — Fri, 18 Jan 2019 07:33:02 GMT

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?

RE: End DFU mesh

Hung Bui — Thu, 17 Jan 2019 16:28:48 GMT

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.