• State Not Answered
  • Replies 22 replies
  • Subscribers 75 subscribers
  • Views 1871 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 343827
Options

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

Parents
  • 0 in reply to Amanda Hsieh

    Hi Amanda,

    Thanks for the suggestion. Upgrading to NCS v2.9.1 isn't a trivial task for us at this point. We've already deployed and validated our current setup (NCS v2.7.0) across over 100 nodes in various locations. Repeating the entire validation process would be quite resource-intensive.

    Is there any workaround or patch that could address the DFU issue within our existing NCS v2.7.0 setup? If not, any guidance on minimizing the impact of migrating to a newer SDK version would be appreciated.

    Best regards,
    Matej

  • 0 in reply to Amanda Hsieh

    Hi Amanda,

    I've cherry-picked all the changes, and everything is working as expected now. I initially assumed the other changes weren't necessary since they were located in the test folder, and it was mentioned that this is a one-line fix. However, it looks like the provisioning info is now retained correctly.

    The provisioner is still showing some errors, even though the firmware update was successfully applied to the nodes.

    What is the recommended procedure for updating the firmware on the provisioner itself? I initially assumed that once the firmware will be distributed to the nodes, the provisioner would also be updated automatically.

    In my test scenario, I had the provisioner with ID 2, and two nodes with IDs 4 and 6. The nodes were in phase 2, and the provisioner—which already had the image—showed phase 10 as expected during the transfer

    Could you also clarify the standard approach for updating the provisioner? I noticed that using the app and selecting "Test + Confirm" successfully updated the provisioner's firmware without any issues.

    Also, do you have any information on the planned release date for v3.1.0? I’ve seen that some preview versions are already available.

    Thank youfor info!

    Best regards,
    Matej

  • 0 in reply to Matej
    Matej said:
    Could you also clarify the standard approach for updating the provisioner? I noticed that using the app and selecting "Test + Confirm" successfully updated the provisioner's firmware without any issues.

    The same flow as you did. See this note in the testing

  • 0 in reply to Amanda Hsieh

    What about release date for v3.1.0?

    Do you have any information on the planned release date for v3.1.0? I’ve seen that some preview versions are already available.

    Thanks.

    BR,

    Matej

  • 0 in reply to Matej

    Probably end of August, but I cannot promise any schedule. 

  • 0 in reply to Matej
    Matej said:

    I've cherry-picked all the changes, and everything is working as expected now. I initially assumed the other changes weren't necessary since they were located in the test folder, and it was mentioned that this is a one-line fix. However, it looks like the provisioning info is now retained correctly.

    The provisioner is still showing some errors, even though the firmware update was successfully applied to the nodes.

    Please note, distributor communicates with the Firmware Update Server model, and BLOB Transfer Server model on the target nodes. Since they are using 0xFFFF as a group address, and since this group address is used to refer to only the 'primary element address' on all nodes, the Firmware Update Server model and BLOB Transfer Server model (both together) serving the firmware update capability must be present on the primary element of the target node. 

    Alternatively, I would ask you to try to use 0xC000 as group address, and subscribe the firmware update related models.

    Additionally, please use latest iOS app, it now support firmware distribution via Mesh, so you won't have to type many commands and do manual subscription configuration of the node.

     

    Matej said:
    What is the recommended procedure for updating the firmware on the provisioner itself? I initially assumed that once the firmware will be distributed to the nodes, the provisioner would also be updated automatically.

    Assuming provisioner is also the distributor - To update firmware on distributor itself, this could be done using Mesh DFU flow. However, in such a case, the only target node that should be present in the list of target nodes is the primary element address of the distributor itself. No other nodes should be present. Once you start the distribution, the distributor will recognize its own address in the target list, and immediately quickly reboot itself to apply the new image.

Reply
  • 0 in reply to Matej
    Matej said:

    I've cherry-picked all the changes, and everything is working as expected now. I initially assumed the other changes weren't necessary since they were located in the test folder, and it was mentioned that this is a one-line fix. However, it looks like the provisioning info is now retained correctly.

    The provisioner is still showing some errors, even though the firmware update was successfully applied to the nodes.

    Please note, distributor communicates with the Firmware Update Server model, and BLOB Transfer Server model on the target nodes. Since they are using 0xFFFF as a group address, and since this group address is used to refer to only the 'primary element address' on all nodes, the Firmware Update Server model and BLOB Transfer Server model (both together) serving the firmware update capability must be present on the primary element of the target node. 

    Alternatively, I would ask you to try to use 0xC000 as group address, and subscribe the firmware update related models.

    Additionally, please use latest iOS app, it now support firmware distribution via Mesh, so you won't have to type many commands and do manual subscription configuration of the node.

     

    Matej said:
    What is the recommended procedure for updating the firmware on the provisioner itself? I initially assumed that once the firmware will be distributed to the nodes, the provisioner would also be updated automatically.

    Assuming provisioner is also the distributor - To update firmware on distributor itself, this could be done using Mesh DFU flow. However, in such a case, the only target node that should be present in the list of target nodes is the primary element address of the distributor itself. No other nodes should be present. Once you start the distribution, the distributor will recognize its own address in the target list, and immediately quickly reboot itself to apply the new image.

Children
No Data
Related
Terms of service