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

[Giannis Anastasopoulos]

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?

[Sigurd Hellesvik]

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

[Giannis Anastasopoulos]

I am not sure how to do this in the present setup as the newer version has many more partitions compared to the old one.

Effectively I am not sure what should I put into thepm_static.yaml. Could you maybe provide an explanation of what are the important parts based on the yaml files I provided?

Thanks a lot for the assistance so far

[Sigurd Hellesvik]

Hi,

NSIB

One thing I just now caught:

You are trying to add an immutable first stage bootloader (NSIB aka b0) in your new project.
This will be hard to impossible to do using Device Firmware Update (DFU).
The first bootloader that runs on your device is immutable, meaning that you can not change it, for security reasons.
Therefore, you can not switch Immutable First Stage MCUboot for a First Stage Nordic Secure Immutable Bootloader (NSIB).

So I guess this is the main reason why your DFU fails here.

Before using pm_static.yml, disable NSIB and try to do DFU again, with only one bootloader.

PM_STATIC.YML

As long as the mcuboot slots are in the same places and of the same size, I think your application should be able to boot just fine.
Keep in mind that if you have non-volatile data in a partition, and change the addresses of this partition, you may loose this non-volatile data after DFU.

To create pm_static, I would start by doing the following:

1. Open sample_pm_static.yml
2. Open your old build/partitions.yml
3. Observe that content in autogenerated file is similar to pm_static file from the two files above.
4. Open <your_project>/pm_static.yml
5. Copy app and mcuboot content from partitions.yml to pm_static.yml
6. Compare with sample_pm_static.yml and remove all parts of yml that is not needed (such as end_address)
7. Try to build project.

Regards,
Sigurd Hellesvik

[Umer Mahmood]

Do you mean, we copy every thing from the auto generated file: ncs_2_5_1_app/build/partitions.yml to the file the file ncs_2_5_1_app/pm_static.yml. Afterwards we should change start address of only these two nodes:

• app
• mcuboot

or should we also modify start addresses of?

• mcuboot_primary, 

  mcuboot_primary_app

  mcuboot_secondary