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,

Thank you for your response.

I would like to ask when the fix is planned to be released. I see that it has already been merged into the main branch—could you please let me know when it is expected to be included in an official v2.9.x release?

Thank you for the info!

BR,
Matej

[Sigurd]

Hi!

It will be part of the next release, which is NCS 3.1.0.

It's 1 line fix, so you can try adding the fix to your 2.9.x project.

[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