questions for DFU of mesh-sdk-2.1.1

[jowei]

Hi friends:

I've followed "DFU quick start guide" and run DFU(from mesh-sdk-2.1.1) example done, the updating time is about 3000 seconds.

(My environment is only 2 devices, one is connected to PC, the other is a mesh node)

I need to implement a reliable DFU feature in our product and try to reduce updating time as low as possible.

So I have some questions:

1.  There is "interval" option of nrfutil, the default is 500ms, when I changed to 100 or 200, updating failed at 20%~30%, until I change to 250ms, the updating is success and reduce about 1500 seconds, so why reducing interval will increase fail rate? Is the bottle neck on "PC to usb-dongle" or " usb-dongle to other nodes"?

2. In "DFU example" of infocenter, that says mesh-DFU has side-by side mode and bootloader-mode, how to run the DFU-bootloader-mode?

Is DFU-bootloader-mode faster than side-by-side mode?

3. For side-by-side-DFU, does mesh node response ack packet whenever it receive any DFU packet?

Is there other mesh-DFU technique documents besides "nordic openmesh github folder"?

4. There is a "ble_app_uart_coexist" example, so it looks like I can integrate ble-dfu(not mesh-dfu) into this example, but I also need mesh-proxy feature, 

So here are two directions:

a. proxy_client+ ble-DFU (not mesh-DFU)

b. ble_app_uart_coexist + ble-DFU + mesh-proxy

Which direction make sense? which direction is easier to implement? 

Thanks you very much.

Joseph

[Bjørn Kvaale]

Sorry for the delayed response. 

Which example application did you transfer over mesh DFU? How big was the hex file generated?

1) In which step of the DFU quick start guide did you change the interval option?

2) The example given in mesh sdk v2.1.1 implements the side-by-side bootloader. The DFU documentation says that the bootloader mode is meant as a fallback mechanism in case the side-by-side bootloader DFU fails. The whole point of side-by-side mesh DFU is that the mesh network can still be running while you are upgrading the application, bootloader and/or softdevice.

The bootloader DFU should be quicker, as the device does not need to listen for mesh packets & dfu packets at the same time & can only focus on the dfu packets. In the bootloader mode, the application is not running. I will ask internally about whether it is possible to use the bootloader mode DFU?

3) Are you referring to this documentation here when you refer to "nordic openmesh github example"? I do not believe there is any other documentation other than the documentation posted on the infocenter (link 1, link 2).

4) Why would you want to use regular dfu instead? Is it to get a quicker firmware update? Or would you want to support both mesh dfu & regular dfu?

[jowei]

Hi Bjorn:

Thanks for reply, below are my answers:

-- We transfer "DFU" example with some adding by us, it's 126K.

1) In step10, by using "-i" option, such as "nrfutil dfu serial -pkg dfu_test.zip -p COM4 -b 115200 -i 100 --mesh"

2)Thanks, if the bootloader mode is quicker, please guide me how to use bootloader mode.

3)Yes, besides I refered your link1 and link2, I also refered openMesh DFU document as following:

https://github.com/NordicPlayground/nRF51-ble-bcast-mesh/tree/master/docs/dfu

4)

a. Yes, we are thinking the possibility of regular DFU, because regular DFU can be done by mobile.

b. We are not sure how meshDFU performance when there are more than 100 nodes(in the future we will verify), besides, sometimes meshDFU failed at nrfutil side, we haven't locate the exactly fail clue.

So we are thinking the possibility of regular DFU even regular DFU will be inconvenient when there are many modes.

c. Light-switch_proxy_client + meshDFU + regular DFU should be the best solution for us, but merging light-switch-proxy-client + regular DFU is not easy for us, could you give me any hint? thank you very much.

Regards,

Joseph 

[Bjørn Kvaale]

Hi Joseph,

Sorry for the delayed response. 

1) It clearly says in the nrfutil dfu help command that the interval option -i should be kept greater than 200 ms and less than 2 seconds. Therefore, it makes sense that the dfu failed when you set -i to 100 ms & it worked when you set this option to 250 ms. Have you tried to enable flow control in the nrfutil command (i.e. -fc)? This could also possibly help.

2) It is not a trivial thing to use the bootloader mode. As the DFU example documentation says, the bootloader mode is only used as a backup (i.e. fallback mechanism) in case the side by side DFU fails.

4a) You should be able to do a mesh DFU via the mobile app too. We have the nRF Mesh app & if you attach one proxy node to your mesh network, you will be able to communicate from the phone to the proxy node via the Proxy bearer.

4b) Do you get any failures when you run the command in the DFU quick start guide: nrfutil dfu serial -pkg dfu_test.zip -p <COM port> -b 115200 -fc --mesh ? Or do you only get the failures when you use the -i option? I am pretty sure this is related to my answer to 1 above.

4c) May I ask what your use case is & why you want to do the update via a smartphone instead of via the computer? I understand that it would be easier to do a background DFU via the smartphone instead of having to run a script on your laptop connected to a nRF52 dev kit. We currently do not have a solution for this, but have requested this as a feature update in the future.

The regular BLE DFU would most likely be quite a bit quicker, but you would need to be in distance of all of the nodes to update the whole mesh network.

Kind Regards,

Bjørn

[jowei]

Hi Bjorn:

Sorry for late response.

We miss flow control indeed, and it looks like mesh DFU has more pros than regular DFU, thanks for your reply.

Joseph