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

[Amanda Hsieh]

Hi, 

Please try NCS v2.9.1.

Regards,
Amanda H.

[Matej]

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

[Matej]

Hi,

I completely understand if this is a simple one-line fix that can be easily applied. However, we still need to consider how to deliver and explain this to the customer.

Returning to the issue: I made changes in mesh_dfu_metadata.py, but unfortunately the firmware was not successfully applied. On the provisioner node, I’m seeing error code 3, while on the node itself I’m getting the following error:

E: JEDEC id [ff ff ff] expect [c2 28 17]

Any ideas?

BR,
Matej

[Amanda Hsieh]

Matej said:

I’m seeing error code 3

Could you provide the error log?

Matej said:

while on the node itself I’m getting the following error:

E: JEDEC id [ff ff ff] expect [c2 28 17]

What board are you using, nRF52840DK or a custom board? 

That error usually indicates an external flash setting issue. Do you connect the external flash via SPI or QSPI? Are you able to run https://github.com/nrfconnect/sdk-zephyr/tree/v3.7.99-ncs2-2/samples/drivers/jesd216 without issue?

[Matej]

Hi Amanda,

I performed few more tests... E: JEDEC id [ff ff ff] expect [c2 28 17] presents on custom board - but there is no external flash. 

Here is situation I'm using two nrf52 dks, one as provisioner, another one as node and one custom board as node.

FW updated was successful and switched but provisioning info was lost.

Then I have implemented bugfix - swapped arguments


And here on the left is log from provisioner, and on the right side are nodes, where FW should be updated but it was not. Nevertheless if there is written that upload succeeded and FW was applying.


In the red on the left side you can see error 3 - log from provisioner, while on the right side there is log from nodes where i'm missing message "Distribution phase changed to Idle"...

For more detailed log it would take more effort since we are already used almost all of the flash. If needed we will need to disable half of features...

Any idea why could applying fix could trigger something like this? Is there any other code where fix should also be applied? maybe switching arguments is needed also within bootloader or what did i miss?

Thank you.

BR,
Matej

[Amanda Hsieh]

Hi, 

https://github.com/nrfconnect/sdk-nrf/pull/22642/files 

It seems more modification than scripts/bluetooth/mesh/mesh_dfu_metadata.py. 

# get PULL request
cd <your NCS folder>/nrf
git fetch ncs pull/22642/head:pr-22642
git checkout pr-22642
west update

Could you try again and let me know the result?

-Amanda H.

[Matej]

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 clarify the standard approach to updating the provisioner as well?

Thank you for support!

Best regards,
Matej