After upgrading mcuboot, the device crashes upon power-up

[Carter]

hi,

  After upgrading mcuboot from NCS 2.6.1 to NCS 2.9.0, the upgrade file is downloaded, and the device restarts and runs normally. The mcuboot version number and active slot are updated as expected. However, when the device is powered off and then powered on again, it fails to work properly, almost as if it has crashed. What could be the cause of this issue?

In NCS 2.6.1, the default value of CONFIG_PM_PARTITION_SIZE_MCUBOOT is 0xc000, while in NCS 2.9.0, the default value is 0xbe00. A bug related to the MCUboot partition size was fixed on October 24, 2024. Could this bug have affected the upgrade failure?

Link:Fix MCUboot partition sizes

[Sigurd Hellesvik]

Hi,

In NCS 2.6.1, the default value of CONFIG_PM_PARTITION_SIZE_MCUBOOT is 0xc000, while in NCS 2.9.0, the default value is 0xbe00. A bug related to the MCUboot partition size was fixed on October 24, 2024. Could this bug have affected the upgrade failure?

Generally, you need to follow the Static partitioning requirement. Im not 100% sure since it is just the headers in this case.

But try to copy build/partitions.yml into pm_static.yml and then build the project for v2.9.0. Does DFU work then?

Regards,
Sigurd Hellesvik

[Carter]

I tried copying build/partitions.yml into pm_static.yml.After upgrading mcuboot from NCS 2.6.1 to NCS 2.9.0, the upgrade file is downloaded, and the device restarts and runs normally. The mcuboot version number and active slot are updated as expected. However, when the device is powered off and then powered on again, it fails to work properly, almost as if it has crashed. 

[Harvey Zheng]

A bit of additional information:
I compared the .config files generated by NCS2.6.1 MCUBoot and NCS2.9.0 MCUBoot. They seem to use different crypto, this is because bootloader\mcuboot\boot\zephyr\external_crypto.conf was merged when compiling NCS2.9.0, which wasn't there when NCS2.6.1 was build!

Will this affect B0's validation of MCUBoot?

[Harvey Zheng]

Hi,

For some reason, I resubmitted a private ticket. It can be seen here

Thanks

[Hieu]

Hi,

Do you want to follow up in the new ticket or here? I am trying to confirm a few things before replying to you.

[Harvey Zheng]

Hi,

I want to follow up in the new ticket.

Thank you.

[Hieu]

This is a follow-up for future readers of this case.

The issue is that there is a feature in NSIB and MCUboot where MCUboot can use the crypto library in NSIB. 

This feature is enabled by default when using Sysbuild (Ref this and this). 
In NCS v2.6.1, Sysbuild isn't the default build method, and it isn't enabled. B0 and MCUboot are built without supporting this feature.
In NCS v2.9.0, Sysbuild is the default method, and MCUboot is built in a way that needs this feature.

When the v2.9.0 MCUboot is flashed onto a device with default v2.6.1 NSIB, it cannot find the crypto library it needs and therefore fails to start.
During the first reset where MCUboot still works that you observe, the MCUboot running is actually the old v2.6.1 one.
During this reset, it swaps the MCUboot from secondary slot into position. The new v2.9.0 MCUboot only runs (and fails) from the second reset.

Currently, the MCUboot-use-b0-crypto feature is always enabled by default in a NSIB+MCUboot+Sysbuild setup. 

For projects that need to upgrade MCUboot to a system without B0 external crypto support, developers can comment out this CMake section as a workaround:
https://github.com/nrfconnect/sdk-nrf/blob/v2.9.0/sysbuild/CMakeLists.txt#L467-L472.

Another workaround is to build with the old parent-child multi-image system instead of Sysbuild.

The issue has been reported, and a fix will be done.