nrf5340 bootloader

RE: nrf5340 bootloader

mke — Wed, 27 Aug 2025 13:04:26 GMT

Hi,

Ok, I understand.

I figured out a solution: I enabled

CONFIG_MCUBOOT_ACTION_HOOKS

And provided the hook. In the hook, if the status is "IMAGE_FOUND", which is reported just before booting the app, I set the "BOOT_MODE_TYPE_BOOTLOADER". The retention mode boot then sees it next reboot, which might be caused by a system crash.

This is good enough for now. Application is not supposed to reboot itself; there is no reason for that normally. But the boot mode can be changed in the application if required etc.

I might enable timeout as well, will think about it. But setting the boot mode already in the bootloader is also satisfactory and pretty safe, I guess.

BR, Madis

RE: nrf5340 bootloader

Vidar Berg — Wed, 27 Aug 2025 12:30:43 GMT

Hi,

Ideally there should be a fallback method to enter serial mode if the updated app is not functional. For example, you can enable BOOT_SERIAL_WAIT_FOR_DFU to make the bootloader always enter serial recovery mode for a specified duration on startup.

[quote user="mke"]So, the bootloader is capable of doing a swapping kind of update for the application image. The only thing I need is to disable the direct write to the primary partition.[/quote]

I do not see any existing Kconfig config settings for serial recovery mode that can be applied to achieve this, so it seems like thus would require you to patch the mcuboot code.

RE: nrf5340 bootloader

mke — Wed, 27 Aug 2025 10:07:15 GMT

Thank you for your comments.

If the bootloader is configured to stay in recovery mode only when there is no application, or via the retention system, the bootloader will boot the image from the primary partition if one is there. Although if the image is wrong and was originally intended for the network core.

Now the application crashes, naturally, and the same process repeats. So there is no way to enter the bootloader, and the device is bricked. As there is no application running capable of entering the bootloader, and bootloader thinks that there is a valid image and boots it. This can happen.

If I use mcumgr image upload -n2, the application image is written to the secondary partition and swapped upon reboot, if requested by "test" or "confirm",

If I then write netcore image with -n2, the image is correctly identified to be for the netcore and updated to there. Although there are few things:-) But bricking the device is not foreseen.

Using -n3 for netcore is the correct one, and writing the image works perfectly. Wrong image gets rejected etc.

So, the bootloader is capable of doing a swapping kind of update for the application image. The only thing I need is to disable the direct write to the primary partition.

Can you hint some configuration options for that, if possible?

BR, Madis

RE: nrf5340 bootloader

Vidar Berg — Wed, 27 Aug 2025 08:04:47 GMT

In serial recovery mode (dfu within the bootloader), you have the option to upload the image directly to the primary slot which removes the possibility to do any pre-validation. But you can always enter serial recovery mode again an reupload the correct image.

Best regards,

Vidar

RE: nrf5340 bootloader

mke — Tue, 26 Aug 2025 10:32:47 GMT

Hello,

Thank you for the hint. It is an elegant solution. Now I have only two partitions and can update both of the cores using the second flash partition.

There is still something that needs improvement, and I need to address it somehow.

Currently, both images are written directly to the target slot after I upload the image using mcumgr, which is ok.

But the problem is that if I write netcore image without using "-n 3" to indicate that the image is supposed to be for the netcore, the image gets written to the application image memory directly, mcuboot_primary.

So there is no "swap/test" functionality in the bootloader. And that can potentially brick the product; if it is possible to brick it, it will happen sooner or later.

So, is it possible to use configuration to force the mcuboot to verify the image before writing it to the final target partition, netcore or appcore main flash partition 1?

The verification seems to be fine for netcore, if I upload zephyr.signed.encrypted.bin image using -n 3, the b0n reports that it was unable to find a valid fw.

In short: updating netcore with the wrong image gets rejected. But updating application core with netcore image is possible, image is directly written without any test/swap or something similar. And this is something I need to fix.

I tried playing with "CONFIG_MCUMGR=y" and its dependencies, but the build fails because of nrf53 hooks get multiple definitions.

BR, Madis

RE: nrf5340 bootloader

Vidar Berg — Mon, 25 Aug 2025 11:25:55 GMT

Hello Madis,

Please have a look at the sample I posted here: RE: Bug in Secure Boot / b0n related partition configuration for nRF5340 under sysbuild in SDK v2.9.0?

Best regards,

Vidar