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,

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.

[Hung Bui]

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

[listenYes]

Hi

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.

[Hung Bui]

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. 

[listenYes]

Hi

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