Guideline for nRF5340 network-core FOTA over MCUmgr (with app-core rollback)

[SelracElosUarg]

Environment

• nRF Connect SDK: v3.2.1
• Zephyr: 4.2.99 (NCS fork)
• CMake (bundled): 3.21.0
• Board: nrf5340dk_nrf5340_cpuapp
• OS: Linux

What already works: application-core FOTA (image 0)

This has worked reliably for a long time:

mcumgr ... image upload -e -n 0 app.signed.bin
mcumgr ... image list          # note new hash in slot 1
mcumgr ... image test <hash>
mcumgr ... reset
mcumgr ... image confirm <hash>

Swap + revert behave exactly as expected.

Goal

Add network-core (hci_ipc) FOTA through MCUmgr in the same way (image 1), without losing the application core's swap/revert.

Config we added

# sysbuild
SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_NETCORE_APP_UPDATE=y
# application prj.conf
CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2

Network-core FOTA steps we follow

mcumgr ... image upload -e -n 1 signed_by_mcuboot_and_b0_hci_ipc.bin
mcumgr ... image list          # image=1 slot=1 appears, secondary magic=good
mcumgr ... image confirm <hash>
mcumgr ... reset               # -> device bricked, only recoverable with: nrfjprog --qspieraseall

What we have tried

In every combination below, staging works fine (image upload -n 1 → image=1 slot=1, magic=good), but the result is always the same: after image test/confirm + reset, the device bricks (reboot loop, only recoverable with nrfjprog --qspieraseall).

• A) SECURE_BOOT_NETCORE + NETCORE_APP_UPDATE only (app core keeps BOOT_SWAP_USING_MOVE). → Brick on reset. RTT shows MCUboot validating image 1 OK, then abort() right after boot_verify_slot_dependencies. The net image seems to go through the app-core swap path. We noticed the network-core swap-skip in boot_slots_compatible() (swap_move.c) is guarded by #ifdef PM_S1_ADDRESS, which is undefined in this config.

• B) Added SECURE_BOOT_APPCORE too (to define PM_S1_ADDRESS). → Build assert PM_S0_SIZE == PM_S1_SIZE; fixed by removing our explicit CONFIG_PM_PARTITION_SIZE_MCUBOOT so PM sizes S0/S1 equally. The device still bricks on reset — now apparently later, possibly during the PCD copy to the network core.

• We have not switched MCUboot to OVERWRITE_ONLY (used by the NCS ref_smp_svr_ext_flash sample for nRF53), because it removes the application core's revert capability, which we need to keep.

So we seem to be missing a config combination: every variant we tried either bricks immediately or bricks "later", always around the network-core update on reset.

Question

Is there a documented minimal configuration for nRF5340 network-core FOTA over MCUmgr (image 1) that coexists with application-core image swap + revert — i.e. without forcing MCUboot into OVERWRITE_ONLY? Does enabling network-core update with BOOT_SWAP_USING_MOVE on the app core require application-core secure boot (B0), or is there a supported combination we are missing?

A reference set of Kconfig options for this exact case would be ideal.

[SelracElosUarg]

"UPDATE" — resolved, but only by giving up application-core rollback

We got network-core FOTA over MCUmgr working, but only by switching MCUboot to overwrite-only. The key was adding:

SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

Full working sysbuild config:

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_NETCORE_APP_UPDATE=y
SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y    # <-- the one that makes it work

# application prj.conf
CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2

With this, the network-core update flow works and the device boots normally (no more brick / reboot loop):

mcumgr ... image upload -e -n 1 signed_by_mcuboot_and_b0_hci_ipc.bin
mcumgr ... image list          # image=1 slot=1, magic=good
mcumgr ... image test <hash>
mcumgr ... reset               # MCUboot does the PCD copy to the net core, boots fine

The important caveat: this is the only combination that works for us. As soon as we keep the application core in a swap mode (BOOT_SWAP_USING_MOVE) to preserve its rollback/revert, the network-core update bricks the device on reset (as described above). SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY is global, so both cores are now overwrite-only — we lost application-core rollback entirely, which was exactly what we were trying to avoid.

So, to be explicit for anyone hitting this:

• Network-core FOTA (image 1) + overwrite-only → works.
• Network-core FOTA + application-core swap/revert → does not work (bricks); we found no supported configuration for it.

If there is a way to keep application-core rollback while still doing network-core FOTA over MCUmgr, we'd still very much like to know — that remains our real goal.

[Hung Bui]

Hi Selrac, 

Thanks for the update. 
Could you let me know if you plan to do DFU update for both cores at the same time (simultaneous FOTA) ? 

Do you use external flash for DFU ? 

I assume you have looked at these guides: 
https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/

https://academy.nordicsemi.com/simultaneous-updates-for-both-cores-of-the-nrf5340/

At step 7.6 it mentioned that rollback has to be disabled. 

As you can find in the guides, the challenge here is that we don't have an option to do rollback on the netcore image. 

The image is replaced directly by the application core via the shared RAM. As far as I know, MCUBoot doesn't have an option to have 2 different mode of swapping for 2 different images. So in this case you don't have an option to have rollback available for application core and overwrite-only for network core. 

[SelracElosUarg]

Hi Hung Bui ,

Thanks for your answer.

My goal is to support both scenarios: simultaneous FOTA updates for both cores, while also retaining the ability to perform FOTA updates of the target core independently. But if just supporting individual updates (non-simultaneous mode) is easier, it is fine for me.

The secondary app must be placed in external RAM, as the application itself is too big to allocate both in internal flash. I am using the same external QSPI flash available on the nRF5340 DK.

I have already gone through the guides you mentioned, and I have now successfully performed a network core FOTA update as pointed in my second comment, however, this was only possible after applying the following configuration (as the guide is pointing):

# STEP 7.6 - Simultaneous FOTA does not support rollback
SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

As soon as I enabled this option, I lost the rollback capability for application core updates.

So, as far as you know, is sacrificing application core rollback functionality a requirement in order to support network core FOTA updates? Or is there a way to achieve both network core FOTA and application core rollback at the same time?

[Hung Bui]

Hi Selrac, 

Could you try CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY=y and don't set SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY ? 

I haven't tried myself but it seems that the configuration is what you need. You can read a little bit more about it here: 
https://nrfconnectdocs.nordicsemi.com/ncs/3.3.1/kconfig/index.html#CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY

https://nrfconnectdocs.nordicsemi.com/ncs/2.4.2/nrf/working_with_nrf/nrf53/nrf5340.html#simultaneous-multi-image-dfu

 Multi-image or non-simultaneous network core update example with BOOT_SWAP_USING_SCRATCH? 

My understanding is that when you do only application core update (only one bin file) you can select to do Test and Confirm. 

But if you send 2 images at the same time you should stick to Confirm only. 

[SelracElosUarg]

I have tried this configuration.
Then the APP CORE is updated properly and the SWAP/ROLLBACK works fine.

BUT, when I try to perform the NET CORE FOTA, the device gets totally bricked until I perform a QSPI Flash erase:

nrfjprog --qspieraseall --family NRF53