Bluetooth mesh dfu cannot be restored after pausing

[llly]

I used the Bluetooth mesh distributor example from ncs2.9.1, and the Bluetooth mesh dfu can proceed normally. However, when I tried to pause and resume the dfu process, I found that it cannot recover from the pause

According to the documentation, I use mesh models dfd suspend to pause the dfu and mesh models dfu cli resume to resume the dfu process.

In the following figure, it can be seen that during the DFU process, I used the pause command.

On the left is the distributor, and on the right is the node that receives new firmware (Bluetooth mesh dfu target example)

Then I sent the mesh models dfu cli resume, wanting the distributor to continue with the dfu process, but the screenshot below would appear. After outputting some logs, the distributor would get stuck, and even sending shell commands would not respond

It seems that after pausing and resuming, the distributor did not receive a response from the node? Do nodes also need to send any commands to successfully recover? But the document does not mention that nodes need to be operated on

[AHaug]

Hello,

According to the documentation, I use mesh models dfd suspend to pause the dfu and mesh models dfu cli resume to resume the dfu process.

Could you point me to which documentation/where in the documentation this is stated so that I can ensure that I'm on the correct page as you?

Kind regards,
Andreas

[llly]

Hello

This is the link to the document

docs.nordicsemi.com/.../dfu_over_bt_mesh.html

[llly]

Sure, I just used the example of target and distributor.

I noticed that after sending the pause command and waiting for two to three seconds, the target's serial port will output a message "bt_mesh_blob_srv: phase_set: Phase: 5".This can also be seen in the screenshot I took earlier (the white box on the right side of the screenshot is the output of the target)

If the recovery command is sent before the target outputs "Phase 5", the situation of "wrong phase: 2 != 3" as shown in the screenshot below will occur. If the recovery command is sent after the target outputs "Phase 5", it is highly likely that the problem I mentioned about the inability to recover the DFU process will occur

[AHaug]

Hi,

Just an update to let you know that I'm waiting for some input from the Mesh team. I will unfortunately not get back to you before early next week with an update.

Thank you for your patience,

Kind regards,
Andreas

[AHaug]

Hi again,

The Mesh team believes what you're observing to be a bug. It's been filed and will be picked up in a coming sprint. It might take a few weeks to be resolved, but I hope you find the news to be good nonetheless.

I will update you when I have an update in the activity for the investigation.

Kind regards,
Andreas

[llly]

Hi

Thank you for your feedback and assistance.

Another question is, are there few people using Bluetooth mesh DFU? Why is there only an example of using shell commands to control Bluetooth mesh DFU in NCS? And the document is not very detailed either.

The method I used to implement Bluetooth mesh dfu in my project is to find the actual API used from the relevant shell command callbacks, and then add it to my project. Although it can also be implemented, it is very troublesome and unlike other functions that have rich public APIs to use

[AHaug]

llly said:

Another question is, are there few people using Bluetooth mesh DFU?

Hmm, I don't have any numbers of the amount of users for Bluetooth Mesh DFU. In the aspect of Mesh's lifetime, then Mesh DFU is relatively new (i.e it was introduced in Mesh specification v1.1 (late 2023), whereas Mesh 1.0 was launched in 2017). Without saying anything conclusive, then the amount of users could be reflected in the current up-time of the feature.

llly said:

Why is there only an example of using shell commands to control Bluetooth mesh DFU in NCS?

Are you asking why only we have an example, or are you asking why there is only 1 sample? If it is the first, then Nordic was very early out with offering the Mesh DFU solution due to how critical such a feature is in specially larger scale Mesh networks. If it is the latter then I think the answer is because it shows the basics of how to implement Mesh DFU

Kind regards,
Andreas

[llly]

What I mean is why there is only this one example about mesh dfu, and why is the dfu process controlled through shell commands?

Submodules like Littlefs have public APIs to operate on them, and can also be operated through mcumgr or shell commands.

But Bluetooth mesh DFU can only be operated through a shell. Although I have identified the APIs behind these shell commands and implemented them in my project, it has added difficulty to my early development