BT FOTA with custom nRF5340 network core

[robertp]

Hi
We would like to use the nRF5340 with a custom network core image that runs the full Bluetooth stack and I have gotten it to work with sysbuild. However, we would like to enable FOTA over Bluetooth also. 
I have a working example with Mcuboot and main application image on the application core, and b0n-bootloader and network image on the network core and it works fine. I have also managed to enable SMP server and can use OS commands when connecting with nRF Connect from my phone, but I can't get image manager to work. It gives some warnings about flash etc. Would it even be possible to have it setup this way? Can the network core run the DFU/FOTA process and work together with mcuboot that is on the application core? 

The reason for this is that we want our application to have minimal amount of interruptions, and having the whole BT stack on the network core seems to otherwise work really good.

Also on top of that we would preferable like to do this without external flash, and I have gotten FOTA to work with only internal flash. But that meant that I had to abandon the custom network image and run with the HCI_IPC image.

nRF Connect SDK v2.9.0

Toolchain v2.9.0

Kind regards

Robert

[AHaug]

Hi,

If you have everything that's specific for BLE, and the netcore don't have any access to the qspi/spi connected to the external flash, then you will need some way to route the transport of the image from netcore -> appcore -> external flash -> mcuboot_secondary partition while uploading.

I'm not certain that this solution is possible. What warnings are you getting?

Kind regards,
Andreas

[robertp]

Hi,
That's the transport-chain I had in mind, except maybe external flash if that can be avoided.

When building my custom net image I have these among my configs: 

CONFIG_NET_BUF=y

CONFIG_MCUMGR=y

CONFIG_MCUMGR_GRP_OS=y

CONFIG_MCUMGR_GRP_OS_BOOTLOADER_INFO=y

CONFIG_ZCBOR=y

CONFIG_MCUMGR_TRANSPORT_BT=y

Which allows me to run some OS manager commands.
When I add  the configs for image manager however I get build errors. 

Config: 

CONFIG_MCUBOOT_BOOTUTIL_LIB=y

CONFIG_IMG_MANAGER=y

CONFIG_FLASH=y

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_STREAM_FLASH=y

CONFIG_MCUMGR_GRP_IMG_CLIENT=y

CONFIG_MCUMGR_GRP_IMG=y

CONFIG_DFU_TARGET=y

Errors:
C:/ncs/v2.9.0/bootloader/mcuboot/boot/bootutil/include/bootutil/bootutil_public.h:44:10: fatal error: flash_map_backend/flash_map_backend.h: No such file or directory
44 | #include <flash_map_backend/flash_map_backend.h>

C:/ncs/v2.9.0/bootloader/mcuboot/boot/bootutil/include/bootutil/fault_injection_hardening.h:57:10: fatal error: mcuboot_config/mcuboot_config.h: No such file or directory
57 | #include "mcuboot_config/mcuboot_config.h"

C:/ncs/v2.9.0/bootloader/mcuboot/boot/bootutil/include/bootutil/bootutil_public.h:44:10: fatal error: flash_map_backend/flash_map_backend.h: No such file or directory
44 | #include <flash_map_backend/flash_map_backend.h>

I suspect this is because Mcuboot isn't completely part of the net image build as it would usually in an application image build. If I configure CONFIG_BOOTLOADER_MCUBOOT=y in my net image it think it attempted and failed to add mcuboot as bootloader for the net core and I don't want that.

Maybe I'm missing some other configs?
I guess I'm wondering if it is even possible to configure it this way?

There will be some sort of communication between the cores, so I think I could set up a way to transport the image to the application core if I can get the network core to accept image uploads.


EDIT: 

Adding CONFIG_FLASH_MAP=y to the network core I get this error instead.

/dfu/img_util/flash_img.c
In file included from C:/ncs/v2.9.0/zephyr/include/zephyr/storage/flash_map.h:300,
from C:/ncs/v2.9.0/zephyr/subsys/dfu/img_util/flash_img.c:13:
C:/ncs/v2.9.0/zephyr/subsys/dfu/img_util/flash_img.c: In function 'flash_img_init':
C:/ncs/v2.9.0/nrf/include/flash_map_pm.h:47:22: error: 'PM_mcuboot_primary_ID' undeclared (first use in this function); did you mean 'PM__mcuboot_primary_ID'?
47 | #define PM_ID(label) PM_##label##_ID
| ^~~

[AHaug]

Hi,

Ah, so there's also the aspect that in NCS 2.7.0 we introduced sysbuild, which is mandatory in NCS v2.9.0. We released a topic on that here today: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/topic/sysbuild-explained/ 

For companion components, previously known as child images, you need to enable them through sysbuild configurations. This means that CONFIG_BOOTLOADER_MCUBOOT=y within prj.conf won't get used, and it has to be added to sysbuild.conf through SB_CONFIG_BOOTLOADER_MCUBOOT=y.

• https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild.html
• https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.html 
• https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/config_and_build/sysbuild/sysbuild_forced_options.html

robertp said:

I suspect this is because Mcuboot isn't completely part of the net image build as it would usually in an application image build. If I configure CONFIG_BOOTLOADER_MCUBOOT=y in my net image it think it attempted and failed to add mcuboot as bootloader for the net core and I don't want that.

Good analysis.I also did some investigation and verified that adding MCUboot through the netcores prj.conf is not supported, as we only support B0N on the netcore. Sizewise MCUboot should fit together with hci_ipc, but other than simply fitting a hex I can't give any guarantee that anything will run.

It is also unfortunately not anything I can commit too much on supporting other than speculation and supplying potentially relevant documentation. Instead we might direct our focus on seeing how we can reach your goals with the "standard" approach where you already have a working solution. I assume that the reason for why you want everything on the netcore is due to being limited on flash memory on the internal flash, so there might be some options.

If this is a feature request, I recommend that you reach out to your regional support director 

Kind regards,
Andreas

[robertp]

Okay, thanks for the feedback. We mostly want everything on the network core to avoid interruptions in the application when zephyr schedules Bluetooth handling, although size could become a problem if we only use internal flash. We might be able to minimize interruptions in other ways. I'll work with the assumption that it is not possible to FOTA the device the way I would like, but if I figure something out I'll update here.

Thanks for your time

[AHaug]

Noted,

Thanks for filling in the motivation. Yes, please let me know if you're able to figure something out w.r.t this solution.

For now, I'll mark the case as closed, but if you have any additional comments you can reopen the discussion yourself. As always, if you have any new topics, please feel free to open new cases in the future

Kind regards,
Andreas