MCUBOOT won't boot image in 2.4.0

[Anthony Ambuehl]

I have an application I have been developing in NCS v2.3.0.  I'm trying now to updata to v2.4.0.

The application targets NRF5340.

It uses NSIB (b0/b0n) and for the application processor also includes mcuboot.

It also uses TF-M and I have implemented a custom service in a secure partition for security features.

It is also configured for mcuboot to use the external flash partition.

The application is based on smp_server and I uses different build configurations to build it either with the console or with smp / mcumgr support.

I have found it necessary to make quite a changes to be compatible with v2.4.0:  Secure partitions have a bunch of changes and I had to change a variety of Kconfig variables as well.  Since my application is drawing from multiple different samples, its hard to know for sure what other changes I may need.

I was eventually able to get the compile to complete cleanly, but I'm finding the mcuboot doesn't find any valid/bootable partition.

In addition no matter what I try, I cannot disable the LOG_MODE_MINIMAL from mcuboot to get more detailed log information.  Even though in child_image/mcuboot.conf has CONFIG_LOG_MODE_MINIMAL=n    the generated mcuboot/zephyr/.config   says CONFIG_LOG_MODE_MINIMAL=y .   I really don't understand why it switches to this value when I specifically requested the opposite.

As well, I cannot debug, since every time I  try to run the debug action in VSCode, I get a write verification failure.

Erasing page at address 0xAB000.
Erasing page at address 0xAC000.
Erasing page at address 0xAD000.
WARNING: A UICR write operation has been requested but UICR has not been
WARNING: erased. Please verify that the result is correct.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Verifying programming.
ERROR: Write verify failed.
FATAL ERROR: command exited with status 25: nrfjprog --program 'd:\AAA\prov\provisioning_image\smp_svr\build_shell\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex' --sectorerase --verify -f NRF53 --coprocessor CP_APPLICATION --snr 1050031166

* The terminal process terminated with exit code: 25.
* Terminal will be reused by tasks, press any key to close it.

So in summary no logs, no debug, and it won't boot.

How should I proceed with resolving this problem?

[Sigurd Hellesvik]

Hi Anthony,

I will continue helping in this case.

Anthony Ambuehl said:

Also it would be wonderful if somehow VSCode would be aware of nrf53_hooks., I had to a perform a global grep of the entire v2.4.0 code base from the shell to locate nrf53_hooks.c, and its still unclear to me how/when this files is used.  With SES at least we always had easy access to all of the source code that was included.  Now its a complete mystery. 

Even worse VSCode actually shows incorrect macro values, I have to determine the correct values by logging them at run time.  For example the value of FIH_BOOT_HOOK_REGULAR reports as 1 in VSCode but reports as 0x19c1f6e1 at run time.  I suppose this is probably an artifact of child images having different config settings.. there needs to be a way to deal with that.

For what it's worth, I agree that our extensions search features have potential for improvement.
I will convey your feedback to our VS Code team, thank you for sharing your thoughts!

Seems to me that you have solved some of the issues in this case.
To avoid misunderstandings:
Do you need help with anything else in this ticket?

Regards,
Sigurd Hellesvik

[Anthony Ambuehl]

Primary issue with mcuboot not working when running with nrf5340dk_nrf5340_cpuapp_ns is resolved after fixing the issue in nrf53_hooks. 

I hope that Nordic can add more testing to the releases to avoid future regressions.

[hugzy123]

Hi,

I think I may be having a similar issue when updating my nrf5340_ns project to ncs v2.4.4.

Does the patch being discussed here just involve changing all instances of "BOOT_HOOK_REGULAR" in "nrf53_hooks.c" to "FIH_BOOT_HOOK_REGULAR" ?

Thanks,

[Hung Bui]

Hi Benjamin, 
This is an old ticket. Have you tried to test with the patch applied ? 
https://github.com/vidarbe/sdk-nrf/commit/00ee7b3e0a562304dca7c8da2d3ad4c5b6cc3e9d

If you used the patch and it still doesn't solve the problem for you , please create a new ticket.