Problems about the DFU over Bluetooth Mesh

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Fri, 01 Mar 2024 00:41:46 GMT

Okay, thank you for always answering my questions. I will create a new ticket. Have a nice vacation!

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Thu, 29 Feb 2024 12:22:09 GMT

Hi Listen,

I would suggest to create a new ticket about PB_remote.

You can mention in the new ticket that the ticket should be handled by Terje, one of my colleagues. He would have more experience with PB-remote.

I will be on parental leave from today for the next few months. I wish you best of luck with the product development.

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Thu, 29 Feb 2024 06:16:00 GMT

I want to do an experiment with PB_remote, and then modify the prj.conf file of mesh_shell according to the link you provided. And my screenshot shows that I can't start Mesh prov pb-gatt.

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Wed, 28 Feb 2024 10:32:09 GMT

Hi Listen,

Could you let me know what you want to do with the mesh_shell test project ?

Note that you can do mesh shell with other samples as well. You just need to enable mesh shell.

I did a quick test on the shell test project and it seems to work fine:

After mesh prov pb-gatt on , I can use the nRF Mesh app on the phone to provision the mesh device. I tested on SDK v2.5.2

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Wed, 28 Feb 2024 06:29:25 GMT

I have modified the file tests/bluetooth/mesh_shell/prj.conf as provided by gitthub, and successfully compiled and downloaded it to the nRF52840 DK development board. However, there seem to be many errors in the shell commands. As shown below:

I don't know how to provisioned it, because trying to enter many provisioned commands also reports errors.

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Tue, 27 Feb 2024 09:24:06 GMT

Hi,

We currently don't have an official sample that show case remote provisioning.
However one of our developer has made some samples:
Remote provisioning with mesh shell:
https://github.com/omkar3141/zephyr/commit/3572b8754556fcea63382b5cf288a4a7ac0eb328

Remote provisioning with sensor light ctrl:
https://github.com/omkar3141/sdk-nrf/tree/omku/demo/v2_5_0_sensor_light_ctrl_with_rpr

We are planning to write a blog on remote provisioning and how to use the library, but I don't know when it's ready, most likely in 2-3 months.

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Tue, 27 Feb 2024 09:16:55 GMT

Yes! DFU has been successful and has been successfully applied and run.Because I only have two development boards now, this is the effect for the time being, but I will buy and use more devices for testing next.

Next, I plan to try the PB-Remote provisioning, but I can't find any sampl. Has NCS v2.5.0 implemented the 5.2.3 PB-Remote process in Mesh Protocol v1.1? If so, how should I conduct the experiment?

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Tue, 27 Feb 2024 08:50:28 GMT

Hi Listen,
I assume that you managed to do a DFU update and can switch to new firmware after that?
Yes performing DFU for mesh would take quite a long time. Mesh has very limited throughput and with Mesh DFU the throughput is limited to avoid network congestion. That's why I suggested to use a small image for testing initially.

On the other hand, Mesh DFU can be done in the background meaning the device can continue to function normally when receiving new image. And also you can do multiple devices at once.

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Tue, 27 Feb 2024 01:27:10 GMT

Thank you again for your answer!

MESH DFU is already able to run normally, but it takes too long. It took about 40 minutes to transfer the 340672-byte bin file. Is this transfer speed normal?

Next, I plan to try the PB-Remote provisioning, but I can't find any sampl. Has NCS v2.5.0 implemented the 5.2.3 PB-Remote process in Mesh Protocol v1.1? If so, how should I conduct the experiment?

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Fri, 23 Feb 2024 08:22:59 GMT

Hi Listen,
You can just enable MCUBoot by

CONFIG_BOOTLOADER_MCUBOOT=y

Then you will have the app_update.bin.
I attached the file just in case it's for nRF52840 DK.

devzone.nordicsemi.com/.../5078.app_5F00_update.bin

Note that the image doesn't confirm itself. So after the first run, if you reset the board, it will roll back to the mesh dfu target application.

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Fri, 23 Feb 2024 03:19:51 GMT

Thank you very much for answering again.!

I am not proficient in NCS, so I don't know how to “update an application which is not Mesh or BLE at all”.

Actually, I don't know how to get an example program to generate a file like app_update.bin (e.g. light simple).

Next, I will follow your suggestions and operate again, providing all the LOGs.

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Thu, 22 Feb 2024 12:44:30 GMT

Hi Listen,

It can be quite difficult to keep track of long question. Please try to keep the question short.

ProductID & VendorID: You can choose what you want. It's not related to the firmware version that is checked when doing DFU.

CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION is more important.

Element starts from 1, which is the primary element, the next element will be element #2.

The metadata composition data /hash is not very important at this stage of testing. The metadata composition hash is only useful for the device to decide if it should keep the composition data or should start provisioning/configuration from scratch because the composition data has been changed.

Please try to just follow what in the documentation about metadata composition , we can come back to this later.

My suggestion is to update an application which is not Mesh or BLE at all, just to make it as small as possible. In that case, the composition hash doesn't make any different. The new firmware will not use it all.

The CoreType thing I will need to check, but in my test I kept it as 1 and it worked for me on a nRF52840.

Please try with CoreType=1.

Please also show us the log on both the distributor and the DFU target.

Please make sure you add and bind the app key to all of the model in both the distributor and the DFU target. Again, please try testing on smaller image before move to the bigger one.

RE: Problems about the DFU over Bluetooth Mesh

listenYes — Thu, 22 Feb 2024 09:05:59 GMT

In the introduction to “Composing the firmware metadata”, there are the following SHELL commands that confuse me.

First, there is the parameter of the "mesh models dfu metadata comp-add" command: The documentation explains as follows:

ProductID & VendorID:Do these two parameters need to correspond to a macro definition in the Device Firmware Update (DFU) target example? Or can they be specified arbitrarily?

Because when generating the target firmware, the macro definition CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="2.0.0+0" was modified, and the explanation is "Vendor-assigned version identifier", which makes me confused.

Secondly, for the parameter of the "mesh models dfu metadata comp-elem-add" command, the parameter list is explained as follows:

Loc: What is the range of values for this parameter? Does it start from 0 or 1? For example, if a device has only one element, should this parameter be 0 or 1?

Meanwhile, the parameters in the documentation are as follows:

But in fact, I found through the nRF Mesh APP that the "BLOB Transfer Server" has a Model ID of 0x1400, and the "Firmware Update Server" has a Model ID of 0x1402. Therefore, I doubt whether the above parameters are correct.

Therefore, I modified and sent the command according to my own understanding, and got the following result:

The 'mesh models dfu metadata encode' command is also different from the documentation. The parameter list of the documentation is as follows:

The parameter list is explained as follows:

The "app_update.bin" file I compiled is 340534 bytes in size in the Device Manager app, so I changed the Size parameter to 340534.

Then I noticed that CoreType=1 in the document represents "Network core", but the nRF52840 I use does not have a Network core, so I set CoreType=0.

Finally, because in the previous step, I set the parameter "Loc" of the "mesh models dfu metadata comp-elem-add" command to 0; therefore, I also set Elems to 0 here.

Finally, my command is as follows:

mesh models dfu metadata encode 2 0 0 0 340534 0 0x1eadd50c 0

Eventually, I got the metadata as follows:

Immediately after that, I proceeded to the next step, and the relevant input and output content of the Shell is as follows:

Based on the result "puase:5" in the yellow box, which is "BT_MESH_DFD_PHASE_FAILED", the explanation is: The firmware distribution procedure has failed. I don't know what I did wrong.

RE: Problems about the DFU over Bluetooth Mesh

Hung Bui — Wed, 21 Feb 2024 13:42:24 GMT

Hi Listen,

Thanks for the detailed description.

[quote user=""]However, there is one problem now: The document prompts that after the firmware is uploaded, the message "Distribution phase changed to Completed" will be printed.[/quote]

This will printout after the DFU distributor has finished the DFU update. It's not related to when you uploading the image to the distributor.

[quote user=""]Send commands through the SHELL to control the firmware for distribution.[/quote]

You need to use SHELL, either by using mcumgr on PC (Shell UART) or by using shell on the mobile app. It's mentioned here:

Since you are already using the phone to send the image, I would suggest to use the shell module on the nRF Connect Device Manager app on the phone.

Here is what it looks like (on Android app):

Notice that it's the Shell on the left corner, not the "Echo" as in your screenshot.

If you type a dummy command for example "test" the device should response with "command not found"

I just found out that the iOS app doesn't support it. But if possible please use the Android app.

Otherwise you would need to enable UART shell in the configuration (CONFIG_SHELL_BACKEND_SERIAL) and use mcumgr on PC to send mesh shell command.

My suggestion is to try testing with a very simple application for example only blink and LED (no mesh) so that the size of the image is small and the DFU process will be quick, for testing.