migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

RE: migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

Vidar Berg — Wed, 04 Mar 2026 13:04:47 GMT

The board files should be updated before the next SDK release.

RE: migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

Achim Kraus — Tue, 03 Mar 2026 19:37:54 GMT

[quote userid="4240" url="~/f/nordic-q-a/127216/migrating-app-using-mcuboot-to-ncs-3-2-3---issue-with-mcuboot-image-ids-automatically-assigned/562417"]Setting zephyr,code-partition seems like the best workaround for now. I will report this internally.[/quote]

Thanks!

(-: EDIT: :-) anyway, I'm looking forward to see the official Nordic support files for both devices being fixed.

RE: migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

Vidar Berg — Tue, 03 Mar 2026 11:41:22 GMT

Thanks. This looks to be an unintended side effect of the commit I found here: https://github.com/nrfconnect/sdk-zephyr/commit/87b1bb8916c913e492e1d37156cb8b846481bb1f. You can see the FIXED_PARTITION_IS_RUNNING_APP_PARTITION() macro depends on the zephyr,code-partition FLASH_LOAD_OFFSET property to determine if the app is running from slot0.

Setting zephyr,code-partition seems like the best workaround for now. I will report this internally.

EDIT: I was a bit too quick when reviewing the code and what you said. I assumed the issue was that zephyr,code-partition was not defined in the devicetree for these boards. But see now that the issue is really that the FLASH_LOAD_OFFSET symbol is being set to "0" because these boards are missing the "DT_CHOSEN_Z_CODE_PARTITION := zephyr,code-partition" line as you already pointed out. Without this line, Kconfig can't "see" the code partition defined in the devicetree.

RE: migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

Achim Kraus — Mon, 02 Mar 2026 16:16:02 GMT

Thanks for you answer.

In the end it's not easy to understand and analyze what happens, especially, if it breaks on an update.

Sometimes even with the migration guide it's not obvious, what needs to be changed to get it working again.

I mainly wrote about that "image IDs", because this was the only change mention in migration guide 3.2 , where I see a relation to the partitions.

Building my app for a Thingy:91, using the pm_static.yml of that, results in:

devzone.nordicsemi.com/.../6378_2E00_pm_2E00_config

and

devzone.nordicsemi.com/.../thingy_2D00_3_2E00_2_2E00_3_2E00_config

Calling "flash_img_init" results then in a context with:

Update area 2 0xc000 size 0x69000 on flash-controller@39000.

LOG_INF("Update area %d 0x%lx size 0x%x on %s.", dfu_context.flash_area->fa_id,
dfu_context.flash_area->fa_off, dfu_context.flash_area->fa_size,
dfu_context.flash_area->fa_dev->name);

And calling "boot_erase_img_bank" then crashes (because that's the part of the active application and not the secondary slot).

Is there a sample for the nRF9160/51, which doesn't use an additional external flash and uses mcuboot? Perfect would be one, which has been retested with NCS 3.2.3.

And did you check the nrf/boards/nordic/thingy91x/Kconfig.defconfig.nrf9151 and the nrf/boards/nordic/thingy91/Kconfig.defconfig about the maybe missing definition of DT_CHOSEN_Z_CODE_PARTITION?

Because, when I add that to those configs, the update works again. So this is either missing in the Nordic files, or there is an alternative way to do so, but then I guess these lines using DT_CHOSEN_Z_CODE_PARTITION are some leftovers and would better be removed not to mix up the users. At least without definition of DT_CHOSEN_Z_CODE_PARTITION I don't see, how that works.

RE: migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

Vidar Berg — Mon, 02 Mar 2026 15:42:28 GMT

Hello,

The assigned image ID number is not the same as the IDs used for the flash partitions. The image ID does not directly control what mcuboot slot to use. Please check the pm_config.h file in your build/<your project name>/zephyr/include/generated/ to see which partition ID 2 maps to.

Setting flash load offset is not necessary when using the partition manager. You can confirm the start address in flash from the zephyr.map output.

Note: you can search your build folder for CONFIG_MCUBOOT_APPLICATION_IMAGE_NUMBER to see what the assigned number is.

Best regards,

Vidar

RE: migrating app using mcuboot to NCS 3.2.3 - issue with MCUboot image IDs automatically assigned?

Achim Kraus — Sun, 01 Mar 2026 09:11:31 GMT

Hmmmm, adding

DT_CHOSEN_Z_CODE_PARTITION := zephyr,code-partition

to boards/nordic/thingy91x/Kconfig.defconfig.nrf9151 , as in boards/nordic/thingy91x/Kconfig.defconfig.nrf5340 , seems to be one possibility to fix it ;-(. The zephyr board definition for the nRF9151-DK seems to use an different approach.

Not sure, which approach would be the preferred by Nordic, but it would help, if the stuff would be more aligned.