MCUboot sign image: possible wrong slot size

[rosc]

I encountered the problem trying a Matter OTA-update and and asking myself why the bootloader wouldn't apply the image:

I am using the partition manager and defining the mcuboot_pad and mcuboot_primary_app partition both in the mcuboot_primary partition. MCUboot uses the mcuboot_primary_app partition value as definition of the maximum allowed partition size. However, both the sign function in nrf/modules/mcuboot/CMakeLists.txt as well as Zephyr use mcuboot_primary as available size for the image.

This leads to the problem that for an app, which exceeds the size of mcuboot_primary_app but is smaller than mcuboot_primary thebuild works fine, signing works as expected, but after the update file is send MCUboot does not apply the image.

I suggest setting

SLOT_SIZE $<TARGET_PROPERTY:partition_manager,PM_MCUBOOT_PRIMARY_APP_SIZE>

instead of

SLOT_SIZE $<TARGET_PROPERTY:partition_manager,PM_MCUBOOT_PRIMARY_SIZE>

Sadly, I haven't figured out where the app size in Zephyr is set, this may also need to be updated.

[Sigurd Hellesvik]

Our developers do not think the line you change is a good fix for this.
Instead, we have another internal ticket on MCUboot and partitioning that we suspect is the cause of this.
MCUboot uses the last part of the secondary slot(I think it is there) to swap images. This means that if the application is too large there may be issues with swapping.
Hopefully when we fix that, this issue will also be solved by the same fix.

[rosc]

Afaik MCUboot uses a special "scratch" partition or does in place swapping, if I am correct? Or might it be the mcuboot pad partition, which would also make sense (which is located before the primary app).

PM_MCUBOOT_PRIMARY_APP_SIZE is smaller than PM_MCUBOOT_PRIMARY_SIZE, since it doesn't include the mcuboot pad partition. I basically ran into the problem that my app was too large (by means of PM_MCUBOOT_PRIMARY_APP_SIZE) but fitted into PM_MCUBOOT_PRIMARY_SIZE, so the OTA overwrote my factory data (located after the app partition).

Afaik zephyr/scripts/imgtool.py is checking the size, so with the smaller size it will create an error during build.

[rosc]

I stand corrected, thanks for the link

Nonetheless, if both pad & app partiton are used to determine the maximum image size, MCUboot will refuse to update. So this may not actually be a problem with the swapping at all, but "just" a wrong size as MCUboot checks afaik against MCUBOOT_PRIMARY_APP_SIZE.

[Sigurd Hellesvik]

How large is your application in comparison to the slot size?
You can easily see this from the bottom of the build log, where it prints percentages

[rosc]

For this special firmware we clocked in at 99.8% of PM_MCUBOOT_PRIMARY_SIZE, so we savely were bigger than PM_MCUBOOT_PRIMARY_APP_SIZE (which is 4 kiB smaller than PM_MCUBOOT_PRIMARY_SIZE).

Please mind that this is not a production firmware, but one with a lot of logs which we needed to evaluate something, so the error does not happen with logging deactivated.

[Sigurd Hellesvik]

rosc said:

For this special firmware we clocked in at 99.8%

Yep, this is the issue I was talking about:

Sigurd Hellesvik said:

Instead, we have another internal ticket on MCUboot and partitioning that we suspect is the cause of this.
MCUboot uses the last part of the secondary slot(I think it is there) to swap images. This means that if the application is too large there may be issues with swapping.
Hopefully when we fix that, this issue will also be solved by the same fix.

So for now, I suggest the following:

Workaround: Make sure that your app is at most 95% of memory. Also, remember to test DFU thoroughly before deploying.

Fix: Wait for a later version of the nRF Connect SDK, cause we will fix the space issue sometime relatively soon.

[olof.stacke]

Is there an update on this issue? Is it fixed in the latest version of nRF Connect SDK?