Problems about the DFU over Bluetooth Mesh

[listenYes]

Hi

I have encountered problems in conducting the mesh DFU test and cannot proceed further.

My test environment is as follows:

(1) Windows 10 System

(2) Visual Studio Code v1.86.2 (installed with the nRF Connect for VS Code extension Pack v2023.11.3 plugin)

(3) nRF52840 DK development board

(4) Ipad 6

(5) NCS v2.5.0

(6) Device Manager v1.6(8)

(7)  nRF Mesh v4.1.0

My reference documents are as follows:

(1)Performing Device Firmware Updates (DFU) in Bluetooth Mesh

(2)DFU over Bluetooth Mesh

(3)Bluetooth Mesh: Device Firmware Update (DFU) distributor

(4)Bluetooth Mesh: Device Firmware Update (DFU) target

Here are my operating steps as detailed as possible:

Configuring and building an application

(1)Copy the distributor and target projects into VS CODE and configure the projects.

In the "APPLICATIONS" tab, generate the default configuration of the distributor and target projects.

(2)Follow the steps as shown in the following figure to build and download the application to two different development boards.

(3)Change the macro definition CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION = "1.0.0+0" to CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION = "2.0.0+0".

Rebuild the target project, and we will get the bin file "app_update.bin" in the build directory. Then place the "app_update.bin" in the shared folder of the nRF Connect application.

So far, after the above operations are completed, I have obtained the following products:

• Two development boards with programs: distributor board; target board; since they are generated using the default project and configuration, their software versions are both v1.0.0.

• An iPad with the app_update.bin file, because I got it by modifying the macro definition CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION to "2.0.0+0", so its software version is v2.0.0.

Provisioning the device

(1)The nRFMesh application adds Application Keys and binds them to the default Primary Network Keys.In the "Settings" tab, click on the "Application Keys" label.

In the upper right corner, click the "+" to create and add Application Keys.

Bind App Key 1 to "Primary Network Keys", and then click "Done" in the top right corner.

(2)Provisioning the distributor board and the target board using the nRFMesh application.Switch to the "Network" tab and click the "+" sign in the upper right corner to add devices.

At this time, two device names, "Mesh DFU Target" and "Mesh DFU Distributor", will be displayed in the device list. First, select the Mesh DFU Distributor device for provisioning (at this time, the four LEDs on the board will blink), and simultaneously enter the Device Capabilities.

Click the "Provision" in the upper right corner and select the "No OOB" option, then the device starts to configure.

After the "Provisioning Complete" popup window appears, click the "OK" option, and you will enter the device page. First, click the "Application Keys" option to add the previous "App Key 1" to the device; then click to enter "Element 1" to bind the four models such as "BLOB Transfer Client", "Firmware Update Client", "BLOB Transfer Server", and "Firmware Update Client" to the just added "App Key 1". Finally, click to enter "Element 2" to bind the two models such as "BLOB Transfer Server" and "Firmware Update Server" to "App Key 1".

Then, perform the same operation on the "Mesh DFU Target" device. This device has only one "Element 1" and only two models: "BLOB Transfer Server" and "Firmware Update Server", which are bound to "App Key 1". At this point, two devices have been added in the "Network" tab, and their models are all bound to App Key 1.

Uploading the firmware to Distributor board

(1)Open the “Device Manager” application.Find and select the “Mesh DFU Distributor” device.Go to the “Image” tab.Press the “ADVANCED” button in the right top corner.Under the “IMAGE UPLOAD” area, press the “Select File” button and select the “app_update.bin” image.Press the “Start” button.

At this time, a popup window will appear, click on the "App Core Slot 1" option.

At this point, the firmware upload to the device begins, but for some reason, the transfer speed is very slow, basically stable at 0.60 kB/s.

At this moment, I noticed that there are some differences between my operation process and the process in Bluetooth Mesh: Device Firmware Update (DFU) distributor. I don't know if such differences originate from the version change of the Device Manager software. The process described in the document is as follows:

Meanwhile, the following LOG output can be seen in the RTT Viewer software:

The result after the progress bar is completed is as follows: In order to confirm that the image has been uploaded to the device, I clicked the "Read" button, and two images appeared in the "IMAGE" area.

At this point, can I assume this way: Slot 0 stores the Mesh DFU Distributor firmware that is currently running, so its version is 1.0.0; Slot 1 stores the newly uploaded and successful Mesh DFU Target firmware, so its version is 2.0.0; and the firmware we want to distribute is the firmware in Slot 1.

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.

However, neither on the serial port assistant nor on the RTT Viewer software, the above prompt appears. So, has my above operation been successful?

Send commands through the SHELL to control the firmware for distribution.

To be honest, my operation has come to a standstill at this point and I can no longer proceed. Because I don't know how to enter commands to perform the next steps.

• According to the guidance of "DFU over Bluetooth Mesh",through the shell management subsystem of MCU manager.

         I read this method and knew that it probably inputs commands through the RTT of J-Link.

• By accessing the Shell module over UART.

         This should be to input commands through the serial port assistant (such as the putty software).

However, through my attempts, neither entering commands in the RTT Viewer software nor in the serial assistant works.

Subsequently, I also tried to send shell commands through the Device Manager, but still failed.

Therefore, could you please tell me how to operate next, so that I can continue the remaining steps?

[Hung Bui]

Hi Listen, 

Thanks for the detailed description. 

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.

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. 

Send commands through the SHELL to control the firmware for distribution.

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. 

[listenYes]

Hi

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.

[Hung Bui]

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. 

[listenYes]

Hi

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.

[Hung Bui]

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. 

5078.app_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. 

[listenYes]

Hi

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?

[Hung Bui]

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. 

[listenYes]

Hi

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?

[Hung Bui]

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. 

[listenYes]

Hi

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.