BLE mesh and FOTA upgrade

[RAlexeev]

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?

[RAlexeev]

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?

[Mttrinh]

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.