Multi-Image FOTA on nRF5340 Using External NAND Flash (App + Net Core)

[Lucas Heitele]

Hi Nordic team,

We’ve implemented a custom firmware update flow for our nRF5340-based device, which supports a robust single-image FOTA process using external NAND flash. The update is downloaded via HTTPS (using fota_download), written to NAND via stream_flash, and installed using MCUboot on the next reboot.

Now we want to extend this flow to support coordinated multi-image updates — specifically App Core and Network Core firmware — with atomic validation and rollback behavior.

---

Current Setup

• Device: nRF5340 (custom hardware)

• Storage: External NAND flash via QSPI

• Transport: Firmware is downloaded via HTTPS using fota_download

• Bootloader: MCUboot

• Flow:

  • Image is stored in NAND (not internal flash)

  • Reboot is triggered via sys_reboot(SYS_REBOOT_COLD)

  • MCUboot detects new image in NAND and swaps it on boot

  • Image is confirmed using boot_write_img_confirmed() if successful

We also have a manual firmware_reswap() function using boot_request_upgrade() for triggering updates when needed, but this is not part of our automated FOTA path.

---

Multi-Image FOTA Goal

We want to:

• Download two images (App Core and Net Core) and store both in external NAND

• Validate both images before allowing any upgrade

• Only proceed if both are valid

• Trigger a coordinated update through MCUboot

• Ensure that if either image fails to install or boot, both are rolled back

---

Open Questions

1. MCUboot + External Flash + Multi-Image:
   Can MCUboot handle multi-image updates from external NAND using:

   kconfig

   KopierenBearbeiten

   CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y CONFIG_NRF53_MULTI_IMAGE_UPDATE=y CONFIG_NRF53_UPGRADE_NETWORK_CORE=y

   Is this officially supported in conjunction with stream_flash and external slots?

2. Download strategy:
   Would you recommend:

   • Downloading and storing two separate images independently?

   • Or combining them into a single bundle to unpack after download?

3. Partitioning and mapping:
   What’s the cleanest way to define partition layout (e.g., via pm_static.yml) to store both images in NAND and allow MCUboot to find them?

4. Image validation:
   What’s the best practice to ensure both images are valid before rebooting?
   Should we compute and compare hashes manually, or use image manager APIs?

5. Rollback consistency:
   How do we ensure both images are rolled back if one fails post-upgrade?
   Does MCUboot handle this natively in multi-image mode, or do we need additional coordination?

6. General advice:
   Are there known limitations, recommended patterns, or pitfalls when doing multi-image OTA updates from NAND flash on the nRF5340?

---

We’re open to customizing parts of this logic ourselves if needed, but would prefer to stick to supported MCUboot patterns where possible.

Thanks in advance for your help and insights!

Best regards,
Lucas

[Sigurd Hellesvik]

Hi,

MCUboot + External Flash + Multi-Image:
Can MCUboot handle multi-image updates from external NAND using:

kconfig

KopierenBearbeiten

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y CONFIG_NRF53_MULTI_IMAGE_UPDATE=y CONFIG_NRF53_UPGRADE_NETWORK_CORE=y

Is this officially supported in conjunction with stream_flash and external slots?

Specifically, MCUboot calls nrf53_hooks.c when doing the dual core swapping. Here, it will perform PCD swap to netcore when the data is swapped from mcuboot_secondary to mcuboot_primary.

I cannnot see any flash operations here, so I guess that will be handled by mcuboot itself. I think MCUboot uses boot_copy_region(), which uses flash_area_write().

So I guess the answer would be "no, stream_flash is not supported as such".

Would you recommend:

• Downloading and storing two separate images independently?

• Or combining them into a single bundle to unpack after download?

Our existing solutions stores two separate images (mcuboot_secondary and mcuboot_secondary_1). See https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/ for an explanation.

What’s the cleanest way to define partition layout (e.g., via pm_static.yml) to store both images in NAND and allow MCUboot to find them?

The partition manager has support for multi-image DFU.

What’s the best practice to ensure both images are valid before rebooting?
Should we compute and compare hashes manually, or use image manager APIs?

I dont think i got a specific recommendation here. Just verify, in whatever way you find best.

How do we ensure both images are rolled back if one fails post-upgrade?
Does MCUboot handle this natively in multi-image mode, or do we need additional coordination?

We do not support rollback for nRF5340 multi-image DFU. Ref Simultaneous multi-image DFU with nRF5340 DK.

Are there known limitations, recommended patterns, or pitfalls when doing multi-image OTA updates from NAND flash on the nRF5340?

Here is what I can think of:

nRF5340 multi-image DFU as support status: Experimental
Rollback is not supported for nRF5340 multi-image DFU.
We do not have integrated support for NAND flash, so you will have to figure out the NAND part yourself.
Check out Known Issues in general

Regards,
Sigurd Hellesvik