MCBoot wrong swap_type flag after update request TEST

[n.marty]

Hi all

After successful installation of an update with the hep of dfu_target module, I am expecting the bootloader to swap the image and boot the new image with swap_type TEST.
I need to know in the firmware if there was a software update and therefore I read out the swap type after startup. I use mcuboot_swap_type() function from mcuboot.h module for that.
Swapping after successful update works fine. The problem is that the swap type is not what I expect. It's always "REVERT", but that makes no sense because I can see that I am running on the new image which was previously updated.
Here the logoutput which shows what I mean:

[00:01:19.006,256] <inf> dfu_target_mcuboot: MCUBoot image upgrade scheduled. Reset device to apply
*** Booting Zephyr OS build v2.6.0-rc1-ncs1-9-g9b5948cc9ef4  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test  <<--- HERE IS SWAPTYPE TEST
I: Bootloader chainload address offset: 0x10000
*** Booting Zephyr OS build v2.6.0-rc1-ncs1-9-g9b5948cc9ef4  ***
Flash regions           Domain          Permissions
00 03 0x00000 0x20000   Secure          rwxl
04 31 0x20000 0x100000  Non-Secure      rwxl

Non-secure callable region 0 placed in flash region 3 with size 32.

SRAM region             Domain          Permissions
00 07 0x00000 0x10000   Secure          rwxl
08 31 0x10000 0x40000   Non-Secure      rwxl

Peripheral              Domain          Status
00 NRF_P0               Non-Secure      OK
01 NRF_CLOCK            Non-Secure      OK
02 NRF_RTC0             Non-Secure      OK
03 NRF_RTC1             Non-Secure      OK
04 NRF_NVMC             Non-Secure      OK
05 NRF_UARTE1           Non-Secure      OK
06 NRF_UARTE2           Secure          SKIP
07 NRF_TWIM2            Non-Secure      OK
08 NRF_SPIM3            Non-Secure      OK
09 NRF_TIMER0           Non-Secure      OK
10 NRF_TIMER1           Non-Secure      OK
11 NRF_TIMER2           Non-Secure      OK
12 NRF_SAADC            Non-Secure      OK
13 NRF_PWM0             Non-Secure      OK
14 NRF_PWM1             Non-Secure      OK
15 NRF_PWM2             Non-Secure      OK
16 NRF_PWM3             Non-Secure      OK
17 NRF_WDT              Non-Secure      OK
18 NRF_IPC              Non-Secure      OK
19 NRF_VMC              Non-Secure      OK
20 NRF_FPU              Non-Secure      OK
21 NRF_EGU1             Non-Secure      OK
22 NRF_EGU2             Non-Secure      OK
23 NRF_DPPIC            Non-Secure      OK
24 NRF_REGULATORS       Non-Secure      OK
25 NRF_PDM              Non-Secure      OK
26 NRF_I2S              Non-Secure      OK
27 NRF_GPIOTE1          Non-Secure      OK

SPM: NS image at 0x20200
SPM: NS MSP at 0x2002c948
SPM: NS reset vector at 0x2e2f9
SPM: prepare to jump to Non-Secure image.
[00:00:00.001,068] <inf> mcuboot_util: Swap type: revert <<--- AND THEN SUDDENLY REVERT!?

I put comments in the logs to point out what is strange.

The update process is based on https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.0.0/nrf/samples/nrf9160/http_application_update/README.html

I need a reliable mechanism to detect if the firmware has changed since last reboot. If swap_type is not reliable, then maybe there's another way? Any suggestions?

best regards

[n.marty]

Hi Simon

Thank you for your reply.

Yes I call boot_write_img_confirmed(). And it works. My problem is about what is going on before calling this function.

The function mcuboot_swap_type() which can be used to read the swap type flag returns a somehow counter-intuitive value. After a successful update - and before calling boot_write_img_confirmed() - I would expect this function to return "TEST". But it doesn't. The return value is "REVERT".

I did not have time yet to check what the return value is after calling boot_write_img_confirmed(). I guess it will be "PERM" or "NONE". Because as far as I understood the swap type flag contains the information about what the bootloader is going to do on the next startup.

I am looking for a feature to detect at boot time if the image changed. This detection has to happen on POST_KERNEL initialization level and before running the selftest which calls boot_write_img_confirmed() on success. After all the tests and reading documentation, I am pretty sure the boot type flag is not suited for this...

Any help on how an image change can be detected is appreciated.

best regards

[n.marty]

The problem is, if the image does not get confirmed after test swap (which is a totally valid case, e.g. when something with the newly installed update is wrong), MCUBoot swaps back the old image on next boot and sets the swap type to "None", which indicates normal boot. There is no information that MCUBoot swapped back the old image. Hence, when only looking at the swap_type flag, it is not possible to distinguish between normal boot and boot after image has been swapped back. Which makes swap_type flag not suited for my needs.

I decided to compile an ID into the firmware image which gets persisted after startup. Comparing the image ID with the persisted ID lets me detect quite well if the image changed.

best regards

[Simon]

n.marty said:

There is no information that MCUBoot swapped back the old image. Hence, when only looking at the swap_type flag, it is not possible to distinguish between normal boot and boot after image has been swapped back. Which makes swap_type flag not suited for my needs.

I agree, that's a good point. 

n.marty said:

I decided to compile an ID into the firmware image which gets persisted after startup. Comparing the image ID with the persisted ID lets me detect quite well if the image changed.

That seems like a good solution.