After the Bluetooth mesh dfu is completed, the distribution network information of the node is cleared

[llly]

I have implemented DFU functionality in my Bluetooth mesh project and used device A as the distributor and device B as the node to be updated. I have already configured both devices and they can communicate with each other. Then I use the distributor to send new firmware to the node. After the node firmware is successfully updated, the original distribution network information of the node is cleared. At this point, the distributor and the node cannot communicate and need to manually reconfigure the distribution network. How can the original distribution network data be retained during DFU updates?

[Hung Bui]

Hi Illy, 
Please describe how you did the DFU update ? 
If you use the phone to send the image please check this similar ticket : BLE Mesh NCS: Provisioned data lost after DFU 

[llly]

Hi

There are two examples in NCS: Bluetooth mesh distributor and Bluetooth mesh target. I am using these two examples to test the performance of mesh DFU.

After downloading these two examples to two devices, the first step is to use a mobile phone to send the new firmware of the node to be updated (i.e. the device running the Bluetooth mesh target) to the distributor, and then control the distributor to send the new firmware received from the mobile phone to the node to be updated through a shell command. In other words, the node to be updated will not directly communicate with the mobile phone, but will forward the new firmware from the mobile phone to the node to be updated through the distributor. Therefore, the erase option on the mobile phone has no effect (the erase nvs partition option is turned off by default during updates, and can only be manually enabled to erase nvs partitions, but I have never enabled it)

[llly]

Hi

After the update is completed, there are no special logs, it just starts normally.In the NRF Mesh app, it appears as an unconfigured node

"original version number of 8e" refers to the app version number before the update, which I have customized

I tested again with 52840dk today (in yesterday's and previous tests, the distributor and two nodes were both 54l15). Use the distributor (54l15dk) to update 52840dk. After the update is completed, the situation remains the same as yesterday, so this issue should not be related to the chip model

[Hung Bui]

Hi Illy, 
Please clarify, the node appear as "unconfigured node" or "unprovisioned node" ? They are different. 
If possible please provide the log on the device get provisioned. 
Have you tried to test with one of our sample (light switch for example) to see if you have the same issue ? 

[Hung Bui]

Please also provide us all the commands you used for doing DFU. What we are suspecting is that the metadata provided was not correct. 
On the target there will be a metadata check call when DFU is starting. You may want to add a breakpoint to see if the meatadata check return that the node has to be reprovisioned. 
So please pay extra attention on how the metadata is generated. Please provide us how you do that. 

[llly]

At build time, a zip upgrade package will be generated, which contains a ble_mesh_metadata.json file. I copied the metadata from here

Then I used the "device manager" mobile app to upload this upgrade package to the distributor

After uploading, use shell commands to operate the dfu process of the distributor

1.Register the firmware using 'mesh models dfu slot add', and fill in three parameters: bin size, version number, and metadata

2.Assuming I need to update a node with a unicast address of 0x0080, add this address to the update list using 'mesh models dfd receivers-add 0x80,0'

3.Start updating with 'mesh models dfd start 0 0'

Waiting for the transmission to complete, the node will automatically attempt to apply the new firmware. After running the new firmware, the issue of becoming an unprovisioned node that I mentioned will occur

Can't this problem be reproduced on your end？

[llly]

Hi

it is unprovisioned. Perhaps the translation software I am using is not very accurate for these professional terms.

What part of the log do you need?

I'll give it a try later.

[Hung Bui]

Hi, 
You may need to turn on mesh logging on the target device and check for the metadata check there. 
Have you tried to test with one of our sample ? We are not able to reproduce the issue here. 

[llly]

How to open metadata related logs? I couldn't find the relevant config options

[Hung Bui]

HI Illy, 
If you have 

CONFIG_LOG=y

and you have UART/RTT log you should be able to see the log. As far as I can see dfu_target.c uses printk() so you should see the log. 
What you need to look for is this line inside dfu_target.c: 

This is the logic when the device decide to unprovision itself or not after DFU update. If the img_effect is 

BT_MESH_DFU_EFFECT_UNPROV then it will be unprovisioned. 

[llly]

Hi

I found this log and it does show that after the update, it will become an unprovisioned node

I now understand why he encountered this situation. When I downloaded the mesh dfu target example to the device and used it to build the generated upgrade package for upgrading, the hash he read and calculated were consistent, and it would not become an unprovisioned device after the upgrade was completed.

But in my own project, the hash calculated based on the metadata of the upgrade package is different from the hash originally included in the upgrade package, resulting in the device becoming an unconfigured device after the unprovisioned is completed.

So why do the hashes calculated in my project differ? The metadata I filled in is correct, and I have tried using a distributor example to upgrade the nodes of my project. The computed hash is also different, which indicates that the problem lies in the nodes of my project

[llly]

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/bt/bt_mesh/dfu_over_bt_mesh.html#manual_metadata_generation

According to the instructions in this document, I manually entered parameters using shell commands and calculated the hash value, which is consistent with the hash value calculated by the device during updates. The problem now is that the hash value in the upgrade package automatically generated during construction is different from the hash value calculated by the device

In the first screenshot, the manually generated hash value is 0xbcce424f, The hash value in the upgrade package is 0xdb33f61b in the second screenshot

Both of these hash values can be found in the device log