• State Not Answered
  • Replies 6 replies
  • Subscribers 86 subscribers
  • Views 369 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 357731
Options

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

Parents
  • 0

    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

  • 0 in reply to Vidar Berg

    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:

    Fullscreen 6378.pm.config Download 
    PM_MCUBOOT_OFFSET=0x0
PM_MCUBOOT_ADDRESS=0x0
PM_MCUBOOT_END_ADDRESS=0xc000
PM_MCUBOOT_SIZE=0xc000
PM_MCUBOOT_NAME=mcuboot
PM_MCUBOOT_REGION=flash_primary
PM_MCUBOOT_ID=0
PM_mcuboot_ID=PM_MCUBOOT_ID
PM_mcuboot_IS_ENABLED=1
PM_0_LABEL=MCUBOOT
PM_MCUBOOT_PAD_OFFSET=0xc000
PM_MCUBOOT_PAD_ADDRESS=0xc000
PM_MCUBOOT_PAD_END_ADDRESS=0xc200
PM_MCUBOOT_PAD_SIZE=0x200
PM_MCUBOOT_PAD_NAME=mcuboot_pad
PM_MCUBOOT_PAD_REGION=flash_primary
PM_MCUBOOT_PAD_ID=1
PM_mcuboot_pad_ID=PM_MCUBOOT_PAD_ID
PM_mcuboot_pad_IS_ENABLED=1
PM_1_LABEL=MCUBOOT_PAD
PM_MCUBOOT_PRIMARY_OFFSET=0xc000
PM_MCUBOOT_PRIMARY_ADDRESS=0xc000
PM_MCUBOOT_PRIMARY_END_ADDRESS=0x75000
PM_MCUBOOT_PRIMARY_SIZE=0x69000
PM_MCUBOOT_PRIMARY_NAME=mcuboot_primary
PM_MCUBOOT_PRIMARY_REGION=flash_primary
PM_MCUBOOT_PRIMARY_ID=2
PM_mcuboot_primary_ID=PM_MCUBOOT_PRIMARY_ID
PM_mcuboot_primary_IS_ENABLED=1
PM_2_LABEL=MCUBOOT_PRIMARY
PM_MCUBOOT_PRIMARY_SPAN="tfm mcuboot_pad app"
PM_TFM_SECURE_OFFSET=0xc000
PM_TFM_SECURE_ADDRESS=0xc000
PM_TFM_SECURE_END_ADDRESS=0x18000
PM_TFM_SECURE_SIZE=0xc000
PM_TFM_SECURE_NAME=tfm_secure
PM_TFM_SECURE_REGION=flash_primary
PM_TFM_SECURE_ID=3
PM_tfm_secure_ID=PM_TFM_SECURE_ID
PM_tfm_secure_IS_ENABLED=1
PM_3_LABEL=TFM_SECURE
PM_TFM_SECURE_SPAN="mcuboot_pad tfm"
PM_MCUBOOT_PRIMARY_APP_OFFSET=0xc200
PM_MCUBOOT_PRIMARY_APP_ADDRESS=0xc200
PM_MCUBOOT_PRIMARY_APP_END_ADDRESS=0x75000
PM_MCUBOOT_PRIMARY_APP_SIZE=0x68e00
PM_MCUBOOT_PRIMARY_APP_NAME=mcuboot_primary_app
PM_MCUBOOT_PRIMARY_APP_REGION=flash_primary
PM_MCUBOOT_PRIMARY_APP_ID=4
PM_mcuboot_primary_app_ID=PM_MCUBOOT_PRIMARY_APP_ID
PM_mcuboot_primary_app_IS_ENABLED=1
PM_4_LABEL=MCUBOOT_PRIMARY_APP
PM_MCUBOOT_PRIMARY_APP_SPAN="app tfm"
PM_TFM_OFFSET=0xc200
PM_TFM_ADDRESS=0xc200
PM_TFM_END_ADDRESS=0x18000
PM_TFM_SIZE=0xbe00
PM_TFM_NAME=tfm
PM_TFM_REGION=flash_primary
PM_TFM_ID=5
PM_tfm_ID=PM_TFM_ID
PM_tfm_IS_ENABLED=1
PM_5_LABEL=TFM
PM_APP_OFFSET=0x18000
PM_APP_ADDRESS=0x18000
PM_APP_END_ADDRESS=0x75000
PM_APP_SIZE=0x5d000
PM_APP_NAME=app
PM_APP_REGION=flash_primary
PM_APP_ID=6
PM_app_ID=PM_APP_ID
PM_app_IS_ENABLED=1
PM_6_LABEL=APP
PM_TFM_NONSECURE_OFFSET=0x18000
PM_TFM_NONSECURE_ADDRESS=0x18000
PM_TFM_NONSECURE_END_ADDRESS=0x73000
PM_TFM_NONSECURE_SIZE=0x5b000
PM_TFM_NONSECURE_NAME=tfm_nonsecure
PM_TFM_NONSECURE_REGION=flash_primary
PM_TFM_NONSECURE_ID=7
PM_tfm_nonsecure_ID=PM_TFM_NONSECURE_ID
PM_tfm_nonsecure_IS_ENABLED=1
PM_7_LABEL=TFM_NONSECURE
PM_TFM_NONSECURE_SPAN="app"
PM_MCUBOOT_SECONDARY_OFFSET=0x75000
PM_MCUBOOT_SECONDARY_ADDRESS=0x75000
PM_MCUBOOT_SECONDARY_END_ADDRESS=0xde000
PM_MCUBOOT_SECONDARY_SIZE=0x69000
PM_MCUBOOT_SECONDARY_NAME=mcuboot_secondary
PM_MCUBOOT_SECONDARY_REGION=flash_primary
PM_MCUBOOT_SECONDARY_ID=8
PM_mcuboot_secondary_ID=PM_MCUBOOT_SECONDARY_ID
PM_mcuboot_secondary_IS_ENABLED=1
PM_8_LABEL=MCUBOOT_SECONDARY
PM_MCUBOOT_SCRATCH_OFFSET=0xde000
PM_MCUBOOT_SCRATCH_ADDRESS=0xde000
PM_MCUBOOT_SCRATCH_END_ADDRESS=0xfc000
PM_MCUBOOT_SCRATCH_SIZE=0x1e000
PM_MCUBOOT_SCRATCH_NAME=mcuboot_scratch
PM_MCUBOOT_SCRATCH_REGION=flash_primary
PM_MCUBOOT_SCRATCH_ID=9
PM_mcuboot_scratch_ID=PM_MCUBOOT_SCRATCH_ID
PM_mcuboot_scratch_IS_ENABLED=1
PM_9_LABEL=MCUBOOT_SCRATCH
PM_EMPTY_0_OFFSET=0xfc000
PM_EMPTY_0_ADDRESS=0xfc000
PM_EMPTY_0_END_ADDRESS=0xfe000
PM_EMPTY_0_SIZE=0x2000
PM_EMPTY_0_NAME=EMPTY_0
PM_EMPTY_0_REGION=flash_primary
PM_EMPTY_0_ID=10
PM_empty_0_ID=PM_EMPTY_0_ID
PM_empty_0_IS_ENABLED=1
PM_10_LABEL=EMPTY_0
PM_NONSECURE_STORAGE_OFFSET=0xfe000
PM_NONSECURE_STORAGE_ADDRESS=0xfe000
PM_NONSECURE_STORAGE_END_ADDRESS=0x100000
PM_NONSECURE_STORAGE_SIZE=0x2000
PM_NONSECURE_STORAGE_NAME=nonsecure_storage
PM_NONSECURE_STORAGE_REGION=flash_primary
PM_NONSECURE_STORAGE_ID=11
PM_nonsecure_storage_ID=PM_NONSECURE_STORAGE_ID
PM_nonsecure_storage_IS_ENABLED=1
PM_11_LABEL=NONSECURE_STORAGE
PM_NONSECURE_STORAGE_SPAN="settings_storage"
PM_SETTINGS_STORAGE_OFFSET=0xfe000
PM_SETTINGS_STORAGE_ADDRESS=0xfe000
PM_SETTINGS_STORAGE_END_ADDRESS=0x100000
PM_SETTINGS_STORAGE_SIZE=0x2000
PM_SETTINGS_STORAGE_NAME=settings_storage
PM_SETTINGS_STORAGE_REGION=flash_primary
PM_SETTINGS_STORAGE_ID=12
PM_settings_storage_ID=PM_SETTINGS_STORAGE_ID
PM_settings_storage_IS_ENABLED=1
PM_12_LABEL=SETTINGS_STORAGE
PM_OTP_OFFSET=0x0
PM_OTP_ADDRESS=0xff8108
PM_OTP_END_ADDRESS=0xff83fc
PM_OTP_SIZE=0x2f4
PM_OTP_NAME=otp
PM_OTP_REGION=otp
PM_MCUBOOT_SRAM_OFFSET=0x0
PM_MCUBOOT_SRAM_ADDRESS=0x20000000
PM_MCUBOOT_SRAM_END_ADDRESS=0x20008000
PM_MCUBOOT_SRAM_SIZE=0x8000
PM_MCUBOOT_SRAM_NAME=mcuboot_sram
PM_MCUBOOT_SRAM_REGION=sram_primary
PM_MCUBOOT_SRAM_SPAN="tfm_sram"
PM_SRAM_SECURE_OFFSET=0x0
PM_SRAM_SECURE_ADDRESS=0x20000000
PM_SRAM_SECURE_END_ADDRESS=0x20008000
PM_SRAM_SECURE_SIZE=0x8000
PM_SRAM_SECURE_NAME=sram_secure
PM_SRAM_SECURE_REGION=sram_primary
PM_SRAM_SECURE_SPAN="tfm_sram"
PM_TFM_SRAM_OFFSET=0x0
PM_TFM_SRAM_ADDRESS=0x20000000
PM_TFM_SRAM_END_ADDRESS=0x20008000
PM_TFM_SRAM_SIZE=0x8000
PM_TFM_SRAM_NAME=tfm_sram
PM_TFM_SRAM_REGION=sram_primary
PM_NRF_MODEM_LIB_CTRL_OFFSET=0x8000
PM_NRF_MODEM_LIB_CTRL_ADDRESS=0x20008000
PM_NRF_MODEM_LIB_CTRL_END_ADDRESS=0x200084e8
PM_NRF_MODEM_LIB_CTRL_SIZE=0x4e8
PM_NRF_MODEM_LIB_CTRL_NAME=nrf_modem_lib_ctrl
PM_NRF_MODEM_LIB_CTRL_REGION=sram_primary
PM_NRF_MODEM_LIB_SRAM_OFFSET=0x8000
PM_NRF_MODEM_LIB_SRAM_ADDRESS=0x20008000
PM_NRF_MODEM_LIB_SRAM_END_ADDRESS=0x20010568
PM_NRF_MODEM_LIB_SRAM_SIZE=0x8568
PM_NRF_MODEM_LIB_SRAM_NAME=nrf_modem_lib_sram
PM_NRF_MODEM_LIB_SRAM_REGION=sram_primary
PM_NRF_MODEM_LIB_SRAM_SPAN="nrf_modem_lib_ctrl nrf_modem_lib_tx nrf_modem_lib_rx nrf_modem_lib_trace"
PM_SRAM_NONSECURE_OFFSET=0x8000
PM_SRAM_NONSECURE_ADDRESS=0x20008000
PM_SRAM_NONSECURE_END_ADDRESS=0x20040000
PM_SRAM_NONSECURE_SIZE=0x38000
PM_SRAM_NONSECURE_NAME=sram_nonsecure
PM_SRAM_NONSECURE_REGION=sram_primary
PM_SRAM_NONSECURE_SPAN="sram_primary nrf_modem_lib_ctrl nrf_modem_lib_tx nrf_modem_lib_rx nrf_modem_lib_trace"
PM_NRF_MODEM_LIB_TX_OFFSET=0x84e8
PM_NRF_MODEM_LIB_TX_ADDRESS=0x200084e8
PM_NRF_MODEM_LIB_TX_END_ADDRESS=0x2000a568
PM_NRF_MODEM_LIB_TX_SIZE=0x2080
PM_NRF_MODEM_LIB_TX_NAME=nrf_modem_lib_tx
PM_NRF_MODEM_LIB_TX_REGION=sram_primary
PM_NRF_MODEM_LIB_RX_OFFSET=0xa568
PM_NRF_MODEM_LIB_RX_ADDRESS=0x2000a568
PM_NRF_MODEM_LIB_RX_END_ADDRESS=0x2000c568
PM_NRF_MODEM_LIB_RX_SIZE=0x2000
PM_NRF_MODEM_LIB_RX_NAME=nrf_modem_lib_rx
PM_NRF_MODEM_LIB_RX_REGION=sram_primary
PM_NRF_MODEM_LIB_TRACE_OFFSET=0xc568
PM_NRF_MODEM_LIB_TRACE_ADDRESS=0x2000c568
PM_NRF_MODEM_LIB_TRACE_END_ADDRESS=0x20010568
PM_NRF_MODEM_LIB_TRACE_SIZE=0x4000
PM_NRF_MODEM_LIB_TRACE_NAME=nrf_modem_lib_trace
PM_NRF_MODEM_LIB_TRACE_REGION=sram_primary
PM_SRAM_PRIMARY_OFFSET=0x10568
PM_SRAM_PRIMARY_ADDRESS=0x20010568
PM_SRAM_PRIMARY_END_ADDRESS=0x20040000
PM_SRAM_PRIMARY_SIZE=0x2fa98
PM_SRAM_PRIMARY_NAME=sram_primary
PM_SRAM_PRIMARY_REGION=sram_primary
PM_NUM=13
PM_ALL_BY_SIZE="mcuboot_pad otp nrf_modem_lib_ctrl EMPTY_0 nrf_modem_lib_rx settings_storage nonsecure_storage nrf_modem_lib_tx nrf_modem_lib_trace tfm_sram mcuboot_sram sram_secure nrf_modem_lib_sram tfm mcuboot tfm_secure mcuboot_scratch sram_primary sram_nonsecure tfm_nonsecure app mcuboot_primary_app mcuboot_secondary mcuboot_primary"

    and

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

  • 0 in reply to Achim Kraus

    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.

Reply
  • 0 in reply to Achim Kraus

    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.

Children
Related
Terms of service