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]

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?