• State Not Answered
  • Replies 3 replies
  • Subscribers 91 subscribers
  • Views 125 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 360908
Options

SWAP_USING_OFFSET support in NCS DFU target / FOTA download

Konstantin Klitenik

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 Reply Children
  • 0 in reply to Samruddhi Jadhav

    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!

  • 0 in reply to Konstantin Klitenik

    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

Related
Terms of service