I've run into an issue with FOTA updates. The issue can be described by the following sequence of events:
- A device is completely erased and programmed with a binary image built on the 1.4.0 SDK. I allow the device to fully boot, and then power cycle it to verify that it continues to operate correctly.
- A FOTA is triggered, with the new binary having been built with SDK 1.5.0
- At the conclusion of the FOTA, things seem to be okay, the new 1.5.0 based version run, and I can see that it calls boot_write_img_confirmed(), and that the return code is 0.
- Rebooting this device leads to it reverting back to the 1.4.0 SDK based build. The boot banner when it does this looks like this:
*** Booting Zephyr OS build v2.4.0-ncs1 *** [00:00:00.366,668] [0m<inf> mcuboot: Starting bootloader[0m [00:00:00.373,168] [0m<inf> mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3[0m [00:00:00.383,270] [0m<inf> mcuboot: Boot source: none[0m [00:00:00.388,854] [0m<inf> mcuboot: Swap type: revert[0m [00:00:00.769,714] [0m<inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3[0m [00:00:28.769,042] [0m<inf> mcuboot: Bootloader chainload address offset: 0x10000[0m [00:00:28.776,916] [0m<inf> mcuboot: Jumping to the first image slot[0m *** Booting Zephyr OS build v2.4.0-ncs1 *** Flash regions Domain Permissions 00 02 0x00000 0x18000 Secure rwxl 03 31 0x18000 0x100000 Non-Secure rwxl Non-secure callable region 0 placed in flash region 2 with size 32.
Repeating this process where the original binary loaded was based on the 1.5.0 SDK yields success (i.e. no revert on step 4).
I surmise that maybe something is mismatched between the 1.4.0 SDK MCUBoot and the 1.5.0 one, but I'm not sure what it could be. I'm building without an immutable bootloader if it matters.
Any ideas for what to look at to diagnose this issue?
