This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE mesh and FOTA upgrade

I am working with nRF Connect SDK using an nRF52840 DK. And I want to realise both BLE mesh and FOTA upgrade. FOTA upgrade example SMP Server Sample works properly for Bluetooth Low Energy (without any mesh). And now I want to integrate this FOTA upgrade into BLE mesh application. Please, tell me, how can I do it in the best way?
I had some attempts to realise it, however I faced some difficulties. I don't know how to stop mesh advertisement, which started by bt_mesh_prov_enable, and run ordinary BLE advertising by bt_le_adv_start. bt_le_adv_stop and bt_mesh_prov_disable didn't stop mesh advertisement, since calling bt_le_adv_start function after them returned EALREADY error code. As I think, I could merely set a flag to upgrade (after pressing a button or some command) and reboot microcontroller, and depending on this flag run the FOTA upgrade sample. But I think that there's a more straightforward way to realise this functionality. Can you explain to me how to merge BLE mesh example and FOTA upgrade properly?

Parents
  • Hi,

    Sorry for the late reply. I spoke to one of our developers about this and it seems like this isn't supported, unfortunately.

  • Hi,

    Sorry for the confusion, it was a misuderstanding of the question.

    Yes, It is possible to realise both BLE Mesh and FOTA. You can disable the mesh stack, and start your own BLE operations for a time period to do this.

    RAlexeev said:
    Why doesn't bt_mesh_prov_disable function stop BLE mesh to allow me to run bt_le_adv_start after it and advertise SMP Service with UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84 and etc.?

    I'm not sure why it doesn't disable the mesh. Have you debgged the code and see if the are any error messages retrning when you call bt_mesh_prov_disable? 

    RAlexeev said:
    And is it an appropriate workaround to reboot the microcontroller with running BLE mesh and run usual FOTA upgrade after it without BLE mesh?

    Yes, it this should be fine doing this.

  • Hi,

    Sorry for the late response.

    I have forwarded this to our team to have a look at. I will update you when I get a response from the team.

  • Response from the team:

    Looks like his crash comes from this call in ble_stop(): bt_conn_cb_register(NULL);

    NULL is not a valid parameter for this function. As far as I know, you can't unregister the conn_cb, and you definitely shouldn't register the same handler multiple times.

    Instead, he should register the handler in bt_ready().

    Other than this, what he's doing looks correct. We will try test this internally.

  • Thank you for your response!

    I don't know why I decided to put NULL as an argument, it seems that I did it reading about bt_conn_auth_cb_register() function. Many thanks for these notes. I fixed everything.

    Also, I've found another error. I called this function bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0);  which included BT_LE_ADV_OPT_USE_NAME in advertising parameters, whereas "ad" argument also contained device name. So I had to choose between using a setting device name explicitly in "ad" structure and calling bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), NULL, 0); and calling bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0); where "ad" structure doesn't contain the device name.

    It seems that now I have the only error, which I described before also. bt_le_adv_stop() returns success, but at the same time there're errors in logs:

    [00:00:35.429,229] <wrn> bt_hci_core: opcode 0x200a status 0x0c
    [00:00:35.429,260] <err> bt_mesh_proxy: Failed to stop advertising (err -5)

  • Mttrinh, thanks again for your assistance!

    I attempted to merge SMP Server sample and Bluetooth Mesh sample and I faced another trouble.

    When I comment out CONFIG_NVS=y then I have such kind of errors after running a firmware:

    [00:00:01.334,686] <err> fs: fs_mkdir:mount point not found!!
    [00:00:01.334,686] <err> bt_settings: settings_subsys_init failed (err -2)
    [00:00:01.334,716] <err> smp_bt_sample: Bluetooth init failed (err -2)


    When I comment out CONFIG_FILE_SYSTEM_LITTLEFS=y and CONFIG_MCUMGR_CMD_FS_MGMT=y then the firmware works and I can upgrade it, using nRF Connect for Mobile.
    After running I have such kind of logs:
    [00:00:00.004,821] <inf> mcuboot: Starting bootloader
    [00:00:00.011,169] <inf> mcuboot: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
    [00:00:00.021,362] <inf> mcuboot: Boot source: none
    [00:00:00.027,008] <inf> mcuboot: Swap type: none
    [00:00:00.367,919] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:00.375,823] <inf> mcuboot: Jumping to the first image slot
    ...


    After upgrading a new firmware I have further logs:
    [00:00:00.004,821] <inf> mcuboot: Starting bootloader
    [00:00:00.011,230] <inf> mcuboot: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
    [00:00:00.021,484] <inf> mcuboot: Boot source: none
    [00:00:00.027,130] <inf> mcuboot: Swap type: test
    [00:00:24.306,457] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:24.314,331] <inf> mcuboot: Jumping to the first image slot
    ...


    And after pressing a button on an nRF52840 DK to reboot a microcontroller I have the firmware reverting back to the initial one before upgrading:
    [00:00:00.004,760] <inf> mcuboot: Starting bootloader
    [00:00:00.011,199] <inf> mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
    [00:00:00.021,423] <inf> mcuboot: Boot source: none
    [00:00:00.027,069] <inf> mcuboot: Swap type: revert
    [00:00:00.368,133] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    [00:00:24.396,881] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:24.404,785] <inf> mcuboot: Jumping to the first image slot
    ...


    And it's again the initial firmware.

    And if I comment out neither CONFIG_NVS=y, nor CONFIG_FILE_SYSTEM_LITTLEFS=y and CONFIG_MCUMGR_CMD_FS_MGMT=y, then I have a compilation error here:
    https://github.com/nrfconnect/sdk-nrf/blob/master/include/flash_map_pm.h#L28-L30 
    So, I want to ask you how to better resolve using CONFIG_SETTINGS_NVS and CONFIG_FILE_SYSTEM_LITTLEFS together? Why is it not supported together?

    If to look commits' history, then I can see that in https://github.com/zephyrproject-rtos/zephyr/commit/e104741b7c11c1299de8916c82754c2fe3bca768#diff-64329b5caa58c4edd14c062478eb9029 commit LittleFS started to use instead of NFFS. But at the same time, it's not supported with CONFIG_SETTINGS_NVS, judging by https://github.com/nrfconnect/sdk-nrf/blob/master/include/flash_map_pm.h#L28-L30. So, please, tell me, how is it better to fix?

  • Hi,

    Sorry for the late reply.

    For the problem with the "Failed to stop advertsing" error. Its seem to be false alarm. It just the Mesh trying to stop the advertising when it is already stopped. Nothing is actually going wrong here.

    As for the problem with the firmware reverting back. The problem occurs when you don't confirm the image when you boot up. You need to call boot_write_img_confirmed() in main to confirm that the update went well.

Reply
  • Hi,

    Sorry for the late reply.

    For the problem with the "Failed to stop advertsing" error. Its seem to be false alarm. It just the Mesh trying to stop the advertising when it is already stopped. Nothing is actually going wrong here.

    As for the problem with the firmware reverting back. The problem occurs when you don't confirm the image when you boot up. You need to call boot_write_img_confirmed() in main to confirm that the update went well.

Children
No Data
Related