DFU for multiple nodes simultaneously

[stefanogradozzi]

Hi,

I made DFU procedure with a distributor (nRF52840 DK) and one target (nRF52840 dongle): procedure completed successfully in approximately 45min

Then I made DFU procedure with a distributor (nRF52840 DK) and two target (nRF52840 dongle): procedure completed successfully in approximately 90min (that is 2*45min)

So it seems that if I have N targets,to update,  the DFU procedure will take about N*45min! A lot of time, in particular if N>>1!

Is there a way to update N targets simultaneously, so that the DFU procedure duration can be the same of the case of only ONE target?

Thanks in advance for your response

[Kenneth]

Hello,

I believe your observation for 1 and 2 nodes are correct. The disitributor maintain a list to check all nodes receive the packets, so it will be some scaling as more nodes are added, but as more nodes are added I don't expect it will scale to N * 45 as N>>1.

Kenneth

[stefanogradozzi]

Ok,

but anyway: Is there a way to update N targets simultaneously (I mean, through a sort of "group" concept?

[Kenneth]

It's possible to distribute the firmware to all nodes, including group addresses, but each node must individually ack each of the packets. Depending on a lot of factors (e.g. number of nodes, relays etc) this will take time, but the distributor will need an ack from each node before sending the next part of the firmware (it will retry the same packet on timeout). So that is why it do take longer time when adding nodes, but it will not scale all the way up to N*45min as N>>1.

Kenneth

[stefanogradozzi]

thank you,

I'll test DFU procedure with more than 2 targets so I'll find on fied what happens

[stefanogradozzi]

Hi,

I tested DFU with 6 targets and the procedure completed successfully in approximately 4h.

But when I tested DFU with 8 targets (and I made i t 2 times) only 6 of them completed with success the procedure, while the other two were dropped.after 20/30 min and failed.

Consider that I made the test in a shield chamber, so It should not be an interference problem

Below the report of the fail situation:

uart:~$ [22:21:54.253,906] <dbg> bt_mesh_blob_cli: rx_block_status: 0x002e: block: 8 status: 10
uart:~$ [22:21:54.253,906] <wrn> bt_mesh_blob_cli: Dropping 0x002e: 10
uart:~$ [22:21:54.253,936] <err> bt_mesh_dfu_cli: Target 0x002e failed: 3
uart:~$ [22:21:54.253,936] <dbg> bt_mesh_blob_cli: blob_cli_broadcast_rsp: 0x002e, pending: 2
uart:~$ [22:21:54.334,808] <dbg> bt_mesh_blob_cli: handle_block_status: status: 10 block: 8 encoding: 0
uart:~$ [22:21:54.334,838] <dbg> bt_mesh_blob_cli: rx_block_status: 0x002f: block: 8 status: 10
uart:~$ [22:21:54.334,838] <wrn> bt_mesh_blob_cli: Dropping 0x002f: 10
uart:~$ [22:21:54.334,869] <err> bt_mesh_dfu_cli: Target 0x002f failed: 3

Is it a problem of a short timeout or an insufficient number of retries?

Is there the possibilities to change some parameters to improve the situation?

Thanks