hw: nRF9160-DK, v1.1.0
Using the McuBoot-Loader of NCS 2.5.1 and the NCS 2.6.1 zephyr dfu module seems to be not longer aligned with it.
A app using NCS 2.5.1 zephyr's dfu (mcuboot_swap_type()) gets:
I 48.926 : Update 352976 bytes, 0.10.104+0 ready after 54 s.
I 48.927 : Image index: 0, Swap type: test
I 48.927 : Rebooting to apply update.
OK
*** Booting nRF Connect SDK v2.5.1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
The first part is the logging output using the zephyr dfu module reading the swap type with mcuboot_swap_type() of a pending update.
NCS 2.5.1 McuBoot reports that as expected-
Using a app build with NCS 2.6.1 zephyr's dfu gets the same:
I 06.492 : Update 350064 bytes, 0.10.104+1 ready after 61 s.
I 06.493 : Image index: 0, Swap type: test
I 06.493 : Rebooting to apply update.
OK
*** Booting nRF Connect SDK v2.5.1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
but the NCS 2.5.1 McuBoot reports a different swap_type.
Even if I read the swap type again with NCS 2.6.1 dfu, I get again:
01.128 : Update 350064 bytes, 0.10.104+1 ready.
I 01.128 : Image index: 0, Swap type: test
Executing the same tests with the Thingy:91 board definitions, it works as expected.
I don't see, why NCS 2.6.1 zephyr's dfu module is reporting a different state calling "mcuboot_swap_type()" than NCS 2.5.1 mcuboot.
The behavior prevents nRF9160-DK (and nRF9160-feathers) from being updated via NCS 2.6.1 zephyr's dfu.
