Attachments (12) Download All
Nordic Case Info
  • Case ID: 303358
Options

[NCS v2.2.0] - Device Firmware Update (DFU) via OTA using BLE

Kevin Lin

Hi 

In order to add DFU function to our custom board (integrating nRF52840) over OTA by using BLE, we refer to the guide named "Adding DFU support to your application" and use the same procedure (include the sample) from the "DFU over Bluetooth" section on nRF52840DK. The upload tool we use is nRF Connect Device Manager (Android-verison 1.5.2).

The result is that when we select the "Test and confirm" option on Device Manager to upgrade firmware (whatever app_update.bin or dfu_application.zip), the state will display "Invalid value (3)" after the procedure is completed. We are not sure if the firmware was successfully upgraded.

In view of this, we searched this issue on Nordic Q&A and found someone with the same problem. The case is here. We refered to the solution in this case to upgrade firmware using "Confirm Only" option. But the result was the same. We recorded two logs. One from nRF Logger app and the other from Minicom. They are as follows.

Fullscreen 6735.nRF_Logger_2023-02-22_10_17_29.log Download

In the minicom log, there is a test log "########## Test Log - Another Image ##########". It means that the current image is using the new image. In addition, you can also confirm the "build time" log to check if the active image is changed.

Fullscreen 4682.minicom_nrf52840dk_dfu_ble-2023-02-22.log Download

The following steps show the process we did.

1. After connect to the nRF52840DK, click "Image" section and choose "ADVANED". Then "READ" the image. It will send the current image information.

2. Choose "BASIC" and select a image file (binary or zip file). After click "START", it will ask you to select mode. Here we choose "Confirm only" and click "START".

3. After the process is completed, the "State" will change. The message is "Invalid value (3)".

4. Check the image information as the same as the first step and you will see that there are two images in nRF52840DK. But the active image is not the new one but the original one.

5. Next, test the "Test and confirm" option as the same as the second step.

6. The result is also the same as the "Confirm only" method.

7. "READ" image again and you will see the active image is changed to the new one and their locations have also changed.

8. Send a "RESET" command to nRF52840DK to test if it will use the new image after reset.

9. "READ" image again and you will see the active is changed to the original one but not the new one, since the image was not successfully confirmed.

Can anyone help with this?

Please feel free to let me know if you need more information.

Thanks.

Best Regards,

Kevin

  • 0

    Hi,

    I will go with you through the code of mcumgr subsystem from where you're getting the error.

    First, have a look here: https://github.com/nrfconnect/sdk-zephyr/blob/0cd59b0c43aa0c9d6682066aca74ac05be094169/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c#L585. This is where handlers for different commands are registered. The confirm or test commands are sent as Write to IMG_MGMT_ID_STATE command to Image group, that means we need to check img_mgmt_state_write method.:

    https://github.com/nrfconnect/sdk-zephyr/blob/0cd59b0c43aa0c9d6682066aca74ac05be094169/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c#L274

    We are looking for places where an error called MGMT_ERR_EINVAL is returned as rc.

    I assume the decoding here: https://github.com/nrfconnect/sdk-zephyr/blob/0cd59b0c43aa0c9d6682066aca74ac05be094169/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c#L290 works, as it is called both when you have confirm=false and confirm=true. The first case seems to be working properly. It sets the pending flag to true. After reset the device is swapping images and runs the new image, which is correct. This method fails when confirm is true, which means the error must come later.

    The hash sent is equal in both cases, so this also doesn't end here: https://github.com/nrfconnect/sdk-zephyr/blob/0cd59b0c43aa0c9d6682066aca74ac05be094169/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c#L305

    Then, the next possible place is here: https://github.com/nrfconnect/sdk-zephyr/blob/0cd59b0c43aa0c9d6682066aca74ac05be094169/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c#L315 where the manager is looking for the image to be confirmed. This method is defined here: https://github.com/nrfconnect/sdk-zephyr/blob/0cd59b0c43aa0c9d6682066aca74ac05be094169/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c#L233-L247 indicating that perhaps CONFIG_IMG_MGMT_UPDATABLE_IMAGE_NUMBER isn't set properly.

    Check this out:

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/kconfig/CONFIG_IMG_MGMT_UPDATABLE_IMAGE_NUMBER.html#std-kconfig-CONFIG_IMG_MGMT_UPDATABLE_IMAGE_NUMBER

    If that's not the case, try going further that path. But I suspect that may be it. The next method is just returning the state of images, which is again called for test and confirm, so should work the same way.

    Hope that helped!

  • 0

    Hello,

    Please go through the First response.

    Have you tried the same using the nRF connect Mobile App? Please give a try and let me know the result.

    Kind Regards,

    Abhijith

  • 0 in reply to Aleksander Nowakowski

    I also asked fw guru to check if there are no issues on the mcumgr side.

  • 0 in reply to Aleksander Nowakowski

    Hi,

    Thank you for your prompt reply. 

    Do you mean that the problem is that the value of CONFIG_IMG_MGMT_UPDATABLE_IMAGE_NUMBER in the configuration is set incorrectly?

    Is my understanding correct? If yes, its default value in .config was as follows:

    Then I added its new value in prj.conf for testing, as follows:

    I also list the prj.conf settings based on guidelines.

    But I was getting a failure when building the example:

    From the build log, it seems that the failure is caused by this reason:

    Is it because the partition is not set, or other reasons? If yes, how do we set up partitions?

    By the way, we use nRF Connect for VS Code (Linux) for development.

    Thanks again for your help.

    Best Regards,

    Kevin

  • 0 in reply to Menon

    Hello,

    Sure, we also tried nRF connect Mobile App. The result seems to be the same as nRF Connect Device Manager. We also recorded the same two logs as above, please refer to below.

    Fullscreen nRF_Connect_Log_2023-02-24_12_42_42.txt Download

    Fullscreen minicom_nrfconnect_nrf52840dk_dfu_ble_2023-02-24.log Download

    Here is the process we did.

    1. Scan results on nRF Connect. you can see the Nordic_LBS device.

    2. Connect to the Nordic_LBS device. the result as follows.

    3. Click "DFU" icon in the upper right corner and choose "Confirm only" option to update.

    4. This is the result after the "Confirm only" process is completed.

    5. Then use "Test and Confirm" option to try again.

    6. This is the result after the "Test and Confirm" process is completed.

    7. Finally, execute the "nrfjprog -r" command to test if the board will boot from the new image.

    Thanks.

    Best Regards,

    Kevin

1 2 3 4
Terms of service