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

[Achim Kraus]

I migrate an app from NCS 3.1.0 to NCS 3.2.3.

Using mcuboot with a Thingy:91 or Thingy:91X fails.

flash_img_init results in a flash_img_context, which uses ID 2, the application_slot0, where the app runs from. That obviously crashes on executing an update.

This seems to be caused by 

CONFIG_FLASH_LOAD_OFFSET=0x0

instead of

CONFIG_FLASH_LOAD_OFFSET=0x50000

which, then causes to use slot0 instead of slot1

According the migration guide 3.2 , the 

"MCUboot image IDs are no longer taken from sysbuild Kconfig options and are instead automatically assigned."

but that seems to fail.

The app uses a static partition file (the same as the Thingy:91). The intention is to use only the internal flash (Thingy:91X, nRF9151-DK).

Currently resulting .configs:

thingy91x_nrf9151dk.config.zip

[Vidar Berg]

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).

[Achim Kraus]

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). 

[Achim Kraus]

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).

[Vidar Berg]

Achim Kraus said:

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 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

Achim Kraus said:

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).

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.

[Achim Kraus]

> 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.