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!