nrf54 with mcuboot

RE: nrf54 with mcuboot

Hieu — Thu, 24 Apr 2025 11:41:07 GMT

Hi Chris,

My apology for the misinformation about FProtect. It turns out that all my knowledge about how it works with the nRF52 and 53 are entirely not applicable for the nRF54L15 anymore. I made a bad assumption. Thank you for pointing out clearly what I was mistaken on.

Hieu

RE: nrf54 with mcuboot

Chris G — Wed, 23 Apr 2025 04:11:50 GMT

Hi Hieu,

Yes I was able to significantly reduce the MCUBoot size with the SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256 which prevents the conditions I mentioned. So currently with 3.0.0-rc2, I don't have any outstanding issues with DFU.

[quote userid="9456" url="~/f/nordic-q-a/120819/nrf54-with-mcuboot/532428"]On the nRF54L15, FProtect has a default block size of 0x1000. I am not fully sure if this is something at the hardware level, but as it is, changing MCUboot's main.c like that doesn't give you the desired effect.[/quote]

On the nrf54l15 FProtect only goes to up to a size of 0xF800 (63488B), so if you your application is placed anywhere at or above 0x10000 the FProtect will fail. I was just pointing out that FProtect seems like it only needs to go to the end of the boot partition (aligned to 1k) and not the start of the app partition. For example, if my boot partition was 0-48kB but I set my mcuboot_primary partition starting at 96kB, mcuboot fails due to this FProtect incorrectly setting the "PROTECT_SIZE". It should still work and protect 0-48kB, but it fails because it tries to protect 0-96kB which is outside range.

For the swap time, I had to set `CONFIG_NRF_RRAM_WRITE_BUFFER_SIZE=y` in the mcuboot.conf to speed the swap time and it seems on par with previous devices.

Chris

RE: nrf54 with mcuboot

Hieu — Tue, 22 Apr 2025 18:18:48 GMT

Hello Chris G,

[quote user=""]1.With the 2.9.1 SDK, I consistently see the image revert if I download it using "Test and Confirm." If I use "Confirm only," the upgrade works correctly and boots my image after the swap. Below are the logs showing the image revert, which occurs without ever launching my application. Note that I don’t see this behavior on a similar application running on the nRF5340. Is this a known issue with the 2.9.x SDK? [/quote]

Not sure if I reproduced your exact observation here, but I tried with "Test and Confirm" and found that:

Swaps take a lot of time. This is recorded in the Known Issue list, see NCSDK-28567.
After the new application was successfully booted once, a reset starts Revert swap, but the expected result would be that the image is already confirmed.

Please let me know if you see anything different.

Looking at the nRF Connect Mobile app, my guess is that the app tried to wait for the new application boot to write confirm, but because of the swap time issue, the wait failed and Confirm is never written.

I further tested by connecting to the new application with the Device Manager app, write Confirm, and manually reset the device. The new application is not swapped anymore. This is as expected.

I am having some technical issue with my setup and can't install v3.0.0-rc2. Could you give both version a few tests to see if I was on to something?

[quote user=""]Do you have any suggestions for reducing the size of MCUboot while keeping logs enabled?[/quote][quote user="Chris G"]Using the v3.0.0-rc2 SDK, I've found that if I don't use the KMU for key storage by setting SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y , the mcuboot image size is reduced by ~20kB which allows me to re-enable FPROTECT and logs in mcuboot.[/quote]

Can I take it that this works for you now?

[quote user=""]

3. In the MCUboot main.c, with CONFIG_FPROTECT enabled, this check tries to protect flash up to the start of the app partition, instead of just the end of the bootloader.
Is that intentional?

#define PROTECT_SIZE (PM_MCUBOOT_PRIMARY_ADDRESS - PM_MCUBOOT_ADDRESS) // PM_MCUBOOT_PRIMARY_ADDRESS becomes PM_MCUBOOT_END_ADDRESS.

If I make that change in main.c to align the protect size to the MCUboot partition size, I’m able to increase the partition size to 0xF800, enable logs, and use FPROTECT in the bootloader. This also removes the need for the mcuboot_primary partition to start at or below 0xF000 when FPROTECT is enabled in the bootloader.

#define PROTECT_SIZE (PM_MCUBOOT_END_ADDRESS - PM_MCUBOOT_ADDRESS)

[/quote]

On the nRF54L15, FProtect has a default block size of 0x1000. I am not fully sure if this is something at the hardware level, but as it is, changing MCUboot's main.c like that doesn't give you the desired effect.

Hieu

RE: nrf54 with mcuboot

Chris G — Fri, 18 Apr 2025 21:51:40 GMT

Using the v3.0.0-rc2 SDK, I've found that if I don't use the KMU for key storage by setting SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y , the mcuboot image size is reduced by ~20kB which allows me to re-enable FPROTECT and logs in mcuboot.