DFU issue - bt_mesh_cli: dropping

[Matej]

Dear,

I’m experiencing an issue with performing DFU over BLE Mesh. I have a setup with one node acting as provisioner and distributor. This node has a new image loaded (with a modified advertising name and updated imgtool_sign_version). Additionally, there is one target node (node 3) added in ble mesh. 

I’ve uploaded the image to the distributor, added a slot, and registered the receiver. However, when I start the distribution and check the status, I receive a response indicating phase 10 and status 0.

This setup used to work occasionally when using SDK v2.6.2. However, after migrating to SDK v2.7.0, the issue consistently appears.

Do you have any idea what might be causing this?

Here is Seggers rtt output:

And commands from app:

I have also tried with image index 1, but nothing...

Any idea, inputs?

Thank you 

Best regards,
Matej

[Matej]

Hi Amanda,

Thank you for your inputs. I've successfully migrated to NCS 2.9.1, and most functionalities appear to be working as expected. However, I'm still encountering issues with DFU.

I tested example within ncs, without any code modifications, and I was able to perform a firmware update through the Device Manager without any problems.

In my custom project, I have enabled the suggested logging, I’m seeing the following output — unfortunately, nothing particularly useful or concrete. Apologies for not sharing the full logs and .config file at this stage, as I’d need to filter out a significant amount of content related to customer

00> Starting the firmware distribution.
00> Slot:
00>   Size:     430487 bytes
00>   FWID:     0304050001000000
00>   Metadata: 030405000100000097910601844419620200
00> D: Distribution Start: slot: 0, appidx: 0, tb: 0, addr: 0000, ttl: 255, apply: 1
00> Distribution phase changed to Transfer Active
00> D: 
00> D: 1 targets
00> D: 5
00> D: 4
00> D: 3
00> D: 2
00> D: 1
00> D: Transfer timed out.
00> D: 
00> W: Dropping 0x0003: 9
00> E: Target 0x0003 failed: 3
00> D: continuing
00> D: 
00> D: 3
00> D: reason: 3, phase: 1, apply: 1
00> Distribution phase changed to Failed

While on the target node, nothing DFU releated does not appear in RTT terminal.

We're exploring the possibility of using the same firmware image for both the distributor and target nodes to simplify field deployment. I suspect this approach might be contributing to the issue.

Is it actually supported to have both DFU client and server roles enabled in a single firmware image? If so, do you have an example project or configuration that demonstrates this setup?

Also, could you clarify what the minimal configuration and required function calls are for both the distributor and target nodes?

Thank you again for your support.

Best regards,
Matej

[Amanda Hsieh]

Matej said:

Is it actually supported to have both DFU client and server roles enabled in a single firmware image? If so, do you have an example project or configuration that demonstrates this setup?

Yes, please refer to Bluetooth Mesh: Device Firmware Update (DFU) distributor and see the Self-update section.

Matej said:

could you clarify what the minimal configuration and required function calls are for both the distributor and target nodes?

It needs to enable the required models in your project configuration:

For the Distributor (DFU client):

CONFIG_BT_MESH_DFD_SRV (Firmware Distribution Server)
CONFIG_BT_MESH_DFU_CLI (Firmware Update Client)
CONFIG_BT_MESH_BLOB_SRV (BLOB Transfer Server)
CONFIG_BT_MESH_BLOB_CLI (BLOB Transfer Client)

For the Target (DFU server):

CONFIG_BT_MESH_DFU_SRV (Firmware Update Server)
CONFIG_BT_MESH_BLOB_SRV (BLOB Transfer Server)

The required function calls are as the Bluetooth Mesh: Device Firmware Update (DFU) distributor demonstrates. 

[Matej]

Dear Amanda,

Thank you for your inputs — I’ve successfully managed to perform the firmware update. However, I’m now encountering an issue where the device lose its provisioning information after DFU, re-provisioning is required.

In initial state when I adding the new node, I call function save_settings within provisioned callback. During normal operation and power cycles everything works fine. After performing DFU, I receive provision_reset callback... Any idea how is or why is this triggered?

The new image includes only minimal changes (a few additional printouts and a version number update); everything else remains the same.

Do you have any insights into what might be causing this?

Best regards,
Matej