Perform FOTA to application built with SPM with application built with TFM

Dear All,

We are want to transition from SDK v1.6.0 to 2.1.0.

At the moment we have several devices that are were programmed with the SPM and now we want to be able to do FOTA on them to version 2.1.0 with the application using TFM.

Preliminary tests are not showing promising results, as the device simply reverts back to the original firmware that was on the device.

Is there perhaps an intermediate step that would be advised?

  • Hi,

    There have been an issue with MCUboot clearing out peripherals and reset their state when going from MCUboot to the secure image.
    This caused failures booting the updated TF-M image.

    A fix for this was suggested in https://github.com/nrfconnect/sdk-trusted-firmware-m/commit/6be90b812d6f1f4249237fe18f065acc8738a06f.

    Do you think this could be the issue you are facing?

    Preliminary tests are not showing promising results, as the device simply reverts back to the original firmware that was on the device.

    Do you have access to any logs showing the reason for reverting?

    Regards,
    Sigurd Hellesvik

  •  

    Thank you for the response.

    From what I see the fix you are suggesting is to be applied on v1.6.0, correct?

    If yes, then the proposed fix is not helpful, as we have devices on the field that we cannot receive back and what we want to do is to be able to send them a FOTA file that will be compiled using SDK v2.1.0, preferably using TFM (as SPM is depracated).

    I am not sure how to get the logs for the reverting. This is what I have:

    11:19:12.758 -> *** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
    11:19:12.758 -> I: Starting bootloader
    11:19:12.758 -> I: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
    11:19:12.758 -> I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
    11:19:12.758 -> I: Boot source: none
    11:19:12.758 -> I: Swap type: test
    11:19:49.386 -> I: Bootloader chainload address offset: 0x10000
    11:19:49.386 -> I: Jumping to the first image slot
    *** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
    11:21:49.434 -> I: Starting bootloader
    11:21:49.434 -> I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
    11:21:49.434 -> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    11:21:49.434 -> I: Boot source: none
    11:21:49.434 -> I: Swap type: revert
    11:21:49.812 -> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    11:22:26.658 -> I: Bootloader chainload address offset: 0x10000
    11:22:26.658 -> I: Jumping to the first image slot
    *** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
    11:22:26.942 -> Flash regions		Domain		Permissions
    11:22:26.942 -> 00 03 0x00000 0x20000 	Secure		rwxl
    11:22:26.942 -> 04 31 0x20000 0x100000 	Non-Secure	rwxl
    11:22:26.942 -> 
    11:22:26.942 -> Non-secure callable region 0 placed in flash region 3 with size 32.
    11:22:26.942 -> 
    11:22:27.128 -> SRAM region		Domain		Permissions
    11:22:27.128 -> 00 07 0x00000 0x10000 	Secure		rwxl
    11:22:27.128 -> 08 31 0x10000 0x40000 	Non-Secure	rwxl


    The device resets due to the hardware watchdog that is set to expire in 2 minutes in the original application (I have tried it as well with 3 mins timeout, same results).

    I also tried to send a FOTA file using the wrong key and that was rejected immediately.

    So effectively what I think that I am looking at is that the MCuboot fails to start the application. Could it be that there is a difference in MCuboot versions used in the different nRF SDKs?

    Is there maybe a fix that you can propose for SDK 2.1.0 as we are not able to change anything on devices working with previous versions?

  • Could it be that we are missing some Kconfig?

    This is what I am using right now:

    CONFIG_BOOTLOADER_MCUBOOT=y
    CONFIG_IMG_MANAGER=y
    CONFIG_IMG_ERASE_PROGRESSIVELY=y
    CONFIG_MCUBOOT_IMG_MANAGER=y
    CONFIG_SECURE_BOOT=y
    CONFIG_DFU_TARGET_MCUBOOT=y
    
    CONFIG_DFU_TARGET=y
    CONFIG_MODEM_KEY_MGMT=y
    CONFIG_DOWNLOAD_CLIENT=y
    CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096
    CONFIG_FOTA_DOWNLOAD=y
    
    CONFIG_REBOOT=y
    CONFIG_JSON_LIBRARY=y
    
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_MPU_ALLOW_FLASH_WRITE=y
    CONFIG_NVS=y

  • And to add a little bit more information, when programming the device with the firmware that is to be FOTA-ed, the MCuboot prints out this information:

    11:52:56.408 -> 
    *** Booting Zephyr OS build v3.1.99-ncs1  ***
    11:56:14.056 -> Attempting to boot slot 0.
    
    11:56:14.056 -> Attempting to boot from address 0x8200.
    11:56:14.056 -> 
    Verifying signature against key 0.
    11:56:14.056 -> 
    Hash: 0x16...2e
    
    11:56:14.056 -> Firmware signature verified.
    11:56:14.056 -> 
    Firmware version 1
    
    11:56:14.102 -> Setting monotonic counter (version: 1, slot: 0)
    
    11:56:14.102 -> Booting (0x8200).
    
    *** Booting Zephyr OS build v3.1.99-ncs1  ***
    11:56:14.527 -> I: Starting bootloader
    11:56:14.527 -> I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    11:56:14.527 -> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    11:56:14.527 -> I: Boot source: none
    11:56:14.527 -> I: Swap type: none
    11:56:14.527 -> I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    11:56:14.527 -> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    11:56:14.527 -> I: Boot source: none
    11:56:14.527 -> I: Swap type: none
    11:56:14.856 -> I: Bootloader chainload address offset: 0x28000
    11:56:14.856 -> I: Jumping to the first image slot
    *** Booting Zephyr OS build v3.1.99-ncs1  ***
    


    And there it is obvious that the MCuboot is looking for an application start to a different address (0x8200) in SDK 2.1.0, instead of 0x10000 that is using on the SDK v1.6.0.

    I hope this information is a bit more helpful

  • Hi,

    the start address is interesting, lets look a bit more into that.

    Can you take your project before and after, and upload their build/partitions.yml?

    Regards,
    Sigurd Hellesvik

Related