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

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?

  • 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. 
  • 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

  • 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

  • The reason for the two hash values being different has also been identified. It is because I used a vendor customized model in my project, but there is still an issue at this time. I have changed BT_MESH_ELEM(0, modelsvendor_modelsto BT_MESH_ELEM(0, models,  BT_MESH_MODEL_NONE)in my project to cancelled the vendor custom model. At this time, the hash value in the upgrade package is consistent with the calculated hash value

    And the two hash values after adding the manufacturer's custom model are the same as those in my previous reply

  • Hi Illy, 


    Please clarify, after you managed to get the same metadata hash, do you still have the issue of the device unprovisioning itself ? 

Related