SWAP_USING_OFFSET support in NCS DFU target / FOTA download

In Zephyr 4.3.0, default swap mode was changed to use OFFSET instead of MOVE. As this is recommended by Zephyr as more efficient method, I wanted to switch to it but ran into problems. In summary, OTA was rejected because it was loaded at the wrong offset (0, instead of one sector off).

Setup: NCS v3.4.0-rc1, nRF54L15, MCUboot with SB_CONFIG_MCUBOOT_MODE_SWAP_USING_OFFSET=y. Secondary slot in external SPI flash. OTA is
performed over cellular via fota_download → dfu_target_mcuboot (CONFIG_DFU_TARGET_MCUBOOT=y, stream-based).

Problem: OTA updates are rejected immediately on reboot. Debugging in MCUboot shows the candidate is staged at the first sector of the
secondary slot, so the swap-using-offset bootloader rejects it in boot_validate_slot():

Secondary header magic detected in first sector, wrong upload address?

(loader.c – the offset mode expects the image to start at the second sector.)

Tracing the write path, dfu_target_mcuboot initializes the stream at secondary_address[img_num] = the partition base (sector 0) and
never applies boot_get_image_start_offset(). I can't find any SWAP_USING_OFFSET / boot_get_image_start_offset awareness anywhere under
nrf/subsys/dfu or nrf/subsys/fota_download. The Zephyr SMP/mcumgr path (img_mgmt, flash_img) does apply the offset, but the NCS
download-based FOTA path does not — so swap-using-offset and dfu_target_mcuboot appear incompatible.

Questions:
1. Is this a known limitation — i.e., does the NCS DFU/FOTA stack (dfu_target_mcuboot / fota_download) currently not support
MCUBOOT_MODE_SWAP_USING_OFFSET?
2. Is offset support planned for the NCS DFU target, and if so, roughly which release?
3. For now, is the recommendation to stay on SWAP_USING_MOVE for products using the download-based FOTA path? (It's still the NCS
default, so I assume yes — just confirming.)

Thanks!

Parents
  • Hi,

    As far as I know, "swap using offset" is not something we have used in samples or tested with. There haven't been any plans so far to add it and unfortunately, we cannot guarantee when it will be supported. A recommendation would be to use "swap using move".

    Best Regards,

    Samruddhi

  • Thanks for confirming — that matches what I found in the code.

    Would Nordic consider adding it?

    1. swap-using-offset is now the default MCUboot mode in upstream Zephyr (4.3), and the MCUboot docs state
    it is preferred over swap-using-move (faster swaps, less overhead, fewer flash-endurance cycles, and one extra usable image sector. So NCS DFU not supporting it leaves the recommended mode unusable for download-based FOTA.
    2. Implementation is small and localized. The offset logic already exists in Zephyr (boot_get_image_start_offset() + the
    first-sector erase in flash_img_init_id(), also used by img_mgmt). dfu_target_mcuboot just doesn't apply it.  It initializes
    dfu_target_stream at the partition base (secondary_address) instead of base + boot_get_image_start_offset(), and doesn't erase the reserved first sector. Porting the flash_img approach into dfu_target_mcuboot_init() (gated on
    CONFIG_MCUBOOT_BOOTLOADER_MODE_SWAP_USING_OFFSET) appears to be a ~30–50 line, single-file change with no new APIs.

    Could you file this as a feature request? For now we'll continue using swap-using-move, but we'd like to move to offset once the DFU path supports it.

    Thanks!

  • Hello,

    I have forwarded your request to the team and will get back to you soon with an update once I receive further information. Thanks for your patience.

    Best Regards,

    Samruddhi

Reply Children
No Data
Related