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?

Achim Kraus — Fri, 07 Aug 2026 09:44:31 GMT

> You should not run into the same issue in SDK v3.4.0 since it no longer uses the Partition Manager.

Maybe on it's own, 3.4 to 3.4 FOTAs.

But the nasty point will be the devices, which uses mcuboot for longer (e.g. 2.6.4) and we will see, if FOTA with a 3.4 app will still work, or break the update path. Small changes in the partitions will usually do so. And some "old bugs/limitations" in 2.6.4 mcuboot will also show their pain.

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

Vidar Berg — Fri, 07 Aug 2026 07:47:48 GMT

[quote userid="5203" url="~/f/nordic-q-a/127216/migrating-app-using-mcuboot-to-ncs-3-2-3---issue-with-mcuboot-image-ids-automatically-assigned/569982"]To be frank: then a map, which of your "NCS supported devices" has been retested for which NCS version would be not too bad. [/quote]

I think it may be worth pointing out that we do have more test coverage for FOTA in general. The limitation is specifically the FOTA testing for this particular board, and since the bug in this case was in the board file itself, it was not detected earlier.

The asset tracker template has now been updated to use SDK v3.4.0

[quote userid="5203" url="~/f/nordic-q-a/127216/migrating-app-using-mcuboot-to-ncs-3-2-3---issue-with-mcuboot-image-ids-automatically-assigned/569983"] Either after Nordic verifies, that mcuboot for the Thingy:91(X) works from internal flash with that NCS or I could spend the time into verifying that (but as I wrote, that will be rather at the end of the year).[/quote]

You should not run into the same issue in SDK v3.4.0 since it no longer uses the Partition Manager. However, if you do run into any problems with DFU when that time comes, I am happy to set up a test on my end to help troubleshoot the issue.

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

Achim Kraus — Fri, 07 Aug 2026 06:15:56 GMT

In the end, if there is not longer a plan to fix it, because 3.4 may obsolete it, then we may close the ticket. Either after Nordic verifies, that mcuboot for the Thingy:91(X) works from internal flash with that NCS or I could spend the time into verifying that (but as I wrote, that will be rather at the end of the year).

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

Achim Kraus — Fri, 07 Aug 2026 06:12:19 GMT

I haven't moved to 3.4 for now, I'm currently not able to spend my time in migrating. It will be rather end of the year. I only started with some very first tests, but e.g. "migrating the partitions to DT without breaking FOTA" is pending.

> not tested against all NCS releases

To be frank: then a map, which of your "NCS supported devices" has been retested for which NCS version would be not too bad.

> I am not sure how relevant this is still

I have a patch, so I can live with it.

But I may be not the only one with struggle, see FOTA downloading but failing to boot into the new image (even if it stay unclear, how that was solved).

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

Vidar Berg — Thu, 06 Aug 2026 07:11:41 GMT

We run nightly FOTA tests (app, delta modem and full modem) on the Thingy:91 X for the asset tracker template though this is not tested against all NCS releases. This is also with secondary slot is located in external flash, which could potentially be relevant here. Anyway, it has been some time since you created this thread and I am not sure how relevant this is still or if you have moved to the v.3.4.0 release and using DT partitioning. There have also been some updates made to the thingy board files in the last few months (https://github.com/nrfconnect/sdk-nrf/commits/main/boards/nordic/thingy91x).

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

Vidar Berg — Wed, 24 Jun 2026 11:26:02 GMT

You definetly have a valid point there. I do not know what test coverage we have for these boards with regards to DFU. I have relayed this feedback internally.

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

Achim Kraus — Wed, 17 Jun 2026 20:23:55 GMT

Isn't the main point, that Nordic decided not to test mcuboot/FOTA for the Thingy91(X)? Because, if it's tested, it's either working or a known issue ;-)

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

Vidar Berg — Wed, 17 Jun 2026 06:27:34 GMT

Yes, sorry, I do not remember the exact details of this issue, but I do remember finding out that it would be fixed as a side effect of moving to static DT partitions. However, we now know that we did not manage to complete the transition for the 91 series in time for the v3.3.x release: https://devzone.nordicsemi.com/f/nordic-q-a/128038/partition-manager-deprecation/566028

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

Achim Kraus — Wed, 17 Jun 2026 06:02:55 GMT

This is still the same issue in NCS 3.3.1!

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.