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. 

[Sigurd Hellesvik]

Do you have logs from NSIB?

[Carter]

How to view the logs of NSIB?

[Sigurd Hellesvik]

When I add NSIB and MCUboot to hello world, it looks like this:

A: NSIB logs

B: MCUboot logs

C: Application logs

So for the DK, it logs by default at least

[Carter]

Can you provide the example you added?

[Sigurd Hellesvik]

0447.hello_world.zip

[Harvey Zheng]

Hi,

I took over the problem and trying to fix him. I've reorganized the problem points.

Problem Description

Our application uses MCUBoot as an upgradeable bootloader in the order NSIB(B0) -> MCUBoot -> Application, now we adapted NCS2.9.0 and tried to upgrade MCUBoot from NCS2.6.1 to NCS2.9.0, after the device receives the upgrade package, confirms it and reset, the log shows that MCUBoot has carried the new upgrade package to the S1 partition, and the S1 partition version read on the application is 2. However, when I reset the device again, the program fails to run to the application, and it seems that the problem has already occurred at B0 or MCUBoot.

Examples

I wrote two examples using NCS2.6.1 and NCS2.9.0 and reproduced it on the nRF9160DK.

Differences between the two test examples:

- NCS2.6.1 examples : Sysbuild is not used.
- NCS2.9.0 examples : Sysbuild is used.

Differences between NCS2.6.1 examples and my application:

- NCS2.6.1 Sample: B0 and MCUBoot configurations are basically the same as my application, the first difference is that the MCUBoot partition size is 0xBE00 to be consistent with NCS2.9.0 example(so far testing has shown that MCUBoot sizes of either 0xBE00 or 0xC000 both cause the above problems); The second difference is that the upgrade package is transmitted using the MCUMGR UART.

Recurrence process and log

1. Compile NCS2.6.1 examples with NCS2.6.1 SDK, program into nRF9160DK.

2. Compile NCS2.9.0 examples with NCS2.9.0 SDK.

3. The uart1 port is used by MCUMGR, running a command line in the NCS2.9.0 example directory to transfer the S1 upgrade package to the nRF9160DK

mcumgr -t 60 --conntype serial --connstring=COM48 image upload .\build\signed_by_mcuboot_and_b0_s1_image.bin

4. Get firmware information

mcumgr -t 60 --conntype serial --connstring=COM48 image list

5. Confirm the firmware

mcumgr -t 60 --conntype serial --connstring=COM48 image confirm <hash> true

6. Press the reset button to reset the DK, after booting you can see that the S1 version has been updated to 2.
7. Press the reset button again, the device does not run to the application, and the logs show that it no longer logs after B0 is ready to jump to the S1 partition (the new MCUBoot firmware for S1 already has log printing enabled).

The two attachments are examples of my tests:

ncs2.6.1.zip

ncs2.9.0.zip

[Harvey Zheng]

Hi Sigurd Hellesvik,

Is there any progress on this issue so far and what further information is needed from my side?

Thanks

[Sigurd Hellesvik]

Looking at the examples you sent, pm_static.yml is mostly commented out.

A pm_static.yml that defined all DFU partitions is required. Try to use the same pm_static.yml for both projects. Does DFU work then?

[Harvey Zheng]

Hi,

Sigurd Hellesvik said:

Looking at the examples you sent, pm_static.yml is mostly commented out.

Yes, I only defined the location of the mcuboot secondary partition, the others are generated at build time, and I've compared the partitions of the two examples using memory report, and they are exactly the same.

Sigurd Hellesvik said:

A pm_static.yml that defined all DFU partitions is required. Try to use the same pm_static.yml for both projects. Does DFU work then?

I tried to use the exact same pm_static.yml in both examples, which defines all partitions, but still the upgrade fails with the same occurrences.

On this basis, I tried to keep the B0 configuration of the NCS 2.9.0 example consistent with the B0 configuration of the NCS 2.6.1 example, mainly by setting the following KCONFIG. Then flash the NCS2.9.0 example directly, and the result is the same, it seems to be unable to start MCUBoot after running B0.

CONFIG_BL_ROT_VERIFY_EXT_API_ENABLED=n
CONFIG_BL_SHA256_EXT_API_ENABLED=n
CONFIG_BL_SECP256R1_EXT_API_ENABLED=n
CONFIG_BL_VALIDATE_FW_EXT_API_ENABLED=n
CONFIG_EXT_API_PROVIDE_EXT_API_ENABLED=n