Error when adding mcuboot for a custom nrf5340 board in the get_flash_area_from_id and dynamic partitioning

I am using a custom board with a nrf5340 and vs code with sdk/toolchain version 3.0.2 and trying to get mcuboot working for FOTA. I have been stepping through mcuboot with my segger and have breakpoints in mcuboot/main.c

I am using dynamic partitioning as recommended.

The error is happening on the second pass through this code within context_boot_go in loader.c:

        for (slot = 0; slot < BOOT_NUM_SLOTS; slot++) {
            fa_id = flash_area_id_from_multi_image_slot(image_index, slot);
            rc = flash_area_open(fa_id, &BOOT_IMG_AREA(state, slot));
            assert(rc == 0);

            if (rc != 0) {
                BOOT_LOG_ERR("Failed to open flash area ID %d (image %d slot %d): %d, "
                             "cannot continue", fa_id, image_index, (int8_t)slot, rc);
                FIH_PANIC;
            }
        }

  • slot = 1
  • flash_map_entries = 5
  • fa_id = 6

which calls:

int flash_area_open(uint8_t id, const struct flash_area **fap)
{
	const struct flash_area *area;

	if (flash_map == NULL) {
		return -EACCES;
	}

	area = get_flash_area_from_id(id);
	if (area == NULL) {
		return -ENOENT;
	}

	if (!device_is_ready(area->fa_dev)) {
		return -ENODEV;
	}

	*fap = area;

	return 0;
}

  • id = 6

which calls flash_map_priv.h:

static inline struct flash_area const *get_flash_area_from_id(int idx)
{
	for (int i = 0; i < flash_map_entries; i++) {
		if (flash_map[i].fa_id == idx) {
			return &flash_map[i];
		}
	}

	return NULL;
}

  • i=4
  • flash_map[i].fa_id = 5

This call returns a -2:

rc = flash_area_open(fa_id, &BOOT_IMG_AREA(state, slot));

  • slot = 1

and finally dies on this call in nrf53_cpunet_mgmt.c 

static void onoff_stop(struct onoff_manager *mgr, onoff_notify_fn notify)
{
	nrf_reset_network_force_off(NRF_RESET, true);

	notify(mgr, 0);
}

Here is the flash:

When I have SB_CONFIG_BOOTLOADER_MCUBOOT=n it runs

I have read Simultaneous updates for both cores of the nRF5340, but get errors when I get to:

 # STEP 7.2 - Add b0n image
SB_CONFIG_SECURE_BOOT_NETCORE=y


the error is:
In file included from /opt/nordic/ncs/v3.0.2/nrf/include/dfu/pcd.h:28,
                 from /opt/nordic/ncs/v3.0.2/bootloader/mcuboot/boot/zephyr/main.c:96:
/opt/nordic/ncs/v3.0.2/nrf/include/dfu/pcd_common.h: In function 'pcd_write_cmd_lock_debug':
/opt/nordic/ncs/v3.0.2/nrf/include/dfu/pcd_common.h:39:25: error: 'PM__PCD_SRAM_ADDRESS' undeclared (first use in this function); did you mean 'PM_SRAM_ADDRESS'?

I have also looked at Exercise 5 – FOTA over Bluetooth Low Energy and loosly followed it, but there are a lot of differences with my using a custom board and spi external flash. 

My regions.yml looks like this when I build successfully:

external_flash:
  base_address: 0x0
  default_driver_kconfig: CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK
  device: DT_CHOSEN(nordic_pm_ext_flash)
  dynamic_partition: null
  name: external_flash
  placement_strategy: start_to_end
  size: 0x1000000
flash_primary:
  base_address: 0x0
  default_driver_kconfig: CONFIG_SOC_FLASH_NRF
  device: flash_controller
  dynamic_partition: null
  name: flash_primary
  placement_strategy: complex
  size: 0x100000
otp:
  base_address: 0xff8100
  default_driver_kconfig: ''
  device: ''
  dynamic_partition: null
  name: otp
  placement_strategy: start_to_end
  size: 0x2fc
sram_primary:
  base_address: 0x20000000
  default_driver_kconfig: ''
  device: ''
  dynamic_partition: sram_primary
  name: sram_primary
  placement_strategy: complex
  size: 0x80000

and my partitions.yml look like this:

app:
  address: 0xc200
  end_address: 0x100000
  region: flash_primary
  size: 0xf3e00
external_flash:
  address: 0xcf4000
  end_address: 0x1000000
  region: external_flash
  size: 0x30c000
littlefs_storage:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xc00000
  placement:
    before:
    - tfm_storage
    - end
  region: external_flash
  size: 0xc00000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    align:
      end: 0x1000
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x100000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf4000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x100000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xf3e00
  span: *id002
mcuboot_secondary:
  address: 0xc00000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xcf4000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xf4000
otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
sram_primary:
  address: 0x20000000
  end_address: 0x20070000
  region: sram_primary
  size: 0x70000

Parents
  • Hi,

    I recommend you follow the same approach as here (which you write you had loosly followed) more or less too the point. This should be valid also for any custom board provdied you have the external flash correctly configured. If that is the problem, can you back-track a bit and make sure you have yor SPI flash configured and working on your custom board with your custom baord files withotu DFU? (see this thread for that)

  • I do have the custom board working with external flash when SB_CONFIG_BOOTLOADER_MCUBOOT=n:

    00> [00:00:02.291,046] <inf> littlefs: littlefs partition at /lfs1
    00> [00:00:02.291,076] <inf> littlefs: LittleFS version 2.9, disk version 2.1
    00> [00:00:02.293,182] <inf> littlefs: FS at w25q128@0:0x0 is 3072 0x1000-byte blocks with 512 cycle
    00> [00:00:02.293,182] <inf> littlefs: partition sizes: rd 512 ; pr 512 ; ca 512 ; la 4096
    00> [00:00:02.309,234] <inf> littlefs: Automount /lfs1 succeeded

    Also, I did mention I followed the article you reference, but got an error when adding this:

     # STEP 7.2 - Add b0n image
    SB_CONFIG_SECURE_BOOT_NETCORE=y

    Here is the error:

    In file included from /opt/nordic/ncs/v3.0.2/nrf/include/dfu/pcd.h:28,
                     from /opt/nordic/ncs/v3.0.2/bootloader/mcuboot/boot/zephyr/main.c:96:
    /opt/nordic/ncs/v3.0.2/nrf/include/dfu/pcd_common.h: In function 'pcd_write_cmd_lock_debug':
    /opt/nordic/ncs/v3.0.2/nrf/include/dfu/pcd_common.h:39:25: error: 'PM__PCD_SRAM_ADDRESS' undeclared (first use in this function); did you mean 'PM_SRAM_ADDRESS'?
       39 | #define PCD_CMD_ADDRESS PM__PCD_SRAM_ADDRESS

    Also since I'm not using qspi, I cannot use this:

    # STEP 6.2 - MCUboot should use external flash
    CONFIG_NORDIC_QSPI_NOR=y
    

    Is there something else I use in it's place?

    When I have all of these:

    SB_CONFIG_NETCORE_HCI_IPC=y
    SB_CONFIG_BOOTLOADER_MCUBOOT=y
    SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
    
    SB_CONFIG_SECURE_BOOT_NETCORE=y
    SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
    SB_CONFIG_NETCORE_APP_UPDATE=y
    SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y
    SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

    I get this error:

    /opt/nordic/ncs/toolchains/ef4fc6722e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `datas' will not fit in region `FLASH'
    /opt/nordic/ncs/toolchains/ef4fc6722e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `FLASH' overflowed by 560 bytes

  • Hi,

    Existing exampls demonstrate all you need for DFU (see also Enabling a bootloader chain using sysbuild) so the only additional thing is supporting SPI flash. You can refer to the project added here (this is not for nRF5340, but the relevant configs are the same. The key additions here is what you find under child_Image, in both he Kconfig (mcuboot.conf) and devicetree (mcuboot.overlay) overlay files. PS: recent SDK versions use sysbuild, so for instanc emcuboot overlay files those would be in  <project folder>/sysbuild/mcuboot/ as you can see some examples of in the SDK.

    If you stil don't have any luck, can you share the full project including a full build log that shows how you build the project and all other build output?

  • Created new project to follow as closelly as I can to the examples. I can build and run it before adding mcuboot. I can flash and here are the logs:

    00> [00:00:00.291,320] <inf> littlefs: littlefs partition at /lfs1
    00> [00:00:00.291,381] <inf> littlefs: LittleFS version 2.9, disk version 2.1
    00> [00:00:00.293,487] <inf> littlefs: FS at w25q128@0:0x0 is 3072 0x1000-byte blocks with 512 cycle
    00> [00:00:00.293,487] <inf> littlefs: partition sizes: rd 512 ; pr 512 ; ca 512 ; la 4096
    00> [00:00:00.309,661] <inf> littlefs: Automount /lfs1 succeeded
    00> *** Booting My Application v0.0.1-1bd145744d83 ***
    00> *** Using nRF Connect SDK v3.0.2-89ba1294ac9b ***
    00> *** Using Zephyr OS v4.0.99-f791c49f492c ***
    00> [00:00:00.309,814] <dbg> app: main: Hello World! djboard (0.0.1+0)
    00> [00:00:00.309,814] <dbg> app: main: Checking voltage configuration
    00> [00:00:00.309,844] <inf> voltage_mgr: change_gpio_voltage: REGOUT = 0xfffffffc
    00> [00:00:00.309,844] <inf> voltage_mgr: change_gpio_voltage: target voltage is 4
    00> [00:00:00.309,844] <inf> voltage_mgr: Target voltage already set. No action needed.
    00> 
    00> [00:00:03.327,239] <dbg> app: main: main loop iteration
    00> [00:00:04.327,392] <dbg> app: main: main loop iteration

    I don't have a LED so I created a custom BLE service with a single notific characteristic, but it doesn't do anything at the moment. Just tells me if ble is running and can connect, which it can through nrf connect for iOS.

    The sysbuild.conf is this when I can build successfully:

    SB_CONFIG_NETCORE_HCI_IPC=y
    SB_CONFIG_BOOTLOADER_MCUBOOT=n
    SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n
    #SB_CONFIG_SECURE_BOOT_NETCORE=y
    #SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
    #SB_CONFIG_NETCORE_APP_UPDATE=y
    #SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y
    #SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

    mcuboot.conf is:

    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_BOOT_MAX_IMG_SECTORS=256

    ipc_radio.conf is:

    CONFIG_SERIAL=y
    CONFIG_UART_CONSOLE=y
    CONFIG_LOG=y

    Memory report shows:

    I flip the switches in sysbuild.conf to:

    SB_CONFIG_NETCORE_HCI_IPC=y
    SB_CONFIG_BOOTLOADER_MCUBOOT=y
    SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
    #SB_CONFIG_SECURE_BOOT_NETCORE=y
    #SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
    #SB_CONFIG_NETCORE_APP_UPDATE=y
    #SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y
    #SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

    I'm currenlty getting the following error during build:

    /opt/nordic/ncs/toolchains/ef4fc6722e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/drivers/flash/libdrivers__flash.a(spi_nor.c.obj):(.rodata.spi_nor_0_config+0x0): undefined reference to `__device_dts_ord_137'

  • Hi,

    Which image do you get this error for (typically your application or MCUboot)? Most likely something is not enabled in Kconfig shat should be. You can check in devicetree_generated.h in the build folder to see what __device_dts_ord_137 represents. See here and here for details on this.

  • I'm not sure what gets the error. Does MCUBoot build first?

    I think I am struggling across the boards with dynamic partitioning and mcuboot. The other project which I first referenced will build but is running into a non-existant flash id it needs, I think.

    Starting over and trying to follow the sample as much as possible, which I did, still deviates in a few areas, notably spi, the external storage being used, and vregh difference. Nonetheless I can get everything working (flash particularly) and building until I add mcuboot. I bet the 137 is related to the flash in some way.

    As in the Simultaneous updates for both cores of the nRF5340, I have:

    The original project above had some more complex structures (boards directory under ipc_radio and mcuboot directories with board specific overlay and conf).

    I still get the same error.

    /opt/nordic/ncs/toolchains/ef4fc6722e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/drivers/flash/libdrivers__flash.a(spi_nor.c.obj):(.rodata.spi_nor_0_config+0x0): undefined reference to `__device_dts_ord_137'

    I do think when I get this built I will have the same get_flash_area_from_id error.

    I see a number of warnings:

    warning: UPDATEABLE_IMAGE_NUMBER (defined at
    /opt/nordic/ncs/v3.0.2/nrf/samples/common/mcumgr_bt_ota_dfu/Kconfig:99, subsys/dfu/Kconfig:96) was
    assigned the value '1' but got the value ''. Check these unsatisfied dependencies:
    (((BOARD_THINGY53_NRF5340_CPUAPP || BOARD_THINGY53_NRF5340_CPUAPP_NS) && SOC_SERIES_NRF53X &&
    NCS_SAMPLE_MCUMGR_BT_OTA_DFU) || (!MCUBOOT && IMG_MANAGER)) (=n). See
    http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_UPDATEABLE_IMAGE_NUMBER and/or look up
    UPDATEABLE_IMAGE_NUMBER in the menuconfig/guiconfig interface. The Application Development Primer,
    Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
    helpful too.
    
    
    warning: MCUBOOT_UPDATE_FOOTER_SIZE (defined at subsys/dfu/Kconfig:55) was assigned the value
    '0x2000' but got the value ''. Check these unsatisfied dependencies: MCUBOOT_IMG_MANAGER (=n),
    IMG_MANAGER (=n). See
    http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUBOOT_UPDATE_FOOTER_SIZE and/or look up
    MCUBOOT_UPDATE_FOOTER_SIZE in the menuconfig/guiconfig interface. The Application Development
    Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
    might be helpful too.
    
    
            ---------------------------------------------------------------------
            --- WARNING: Using a bootloader without pm_static.yml.            ---
            --- There are cases where a deployed product can consist of       ---
            --- multiple images, and only a subset of these images can be     ---
            --- upgraded through a firmware update mechanism. In such cases,  ---
            --- the upgradable images must have partitions that are static    ---
            --- and are matching the partition map used by the bootloader     ---
            --- programmed onto the device.                                   ---
            ---------------------------------------------------------------------

  • Any update on this? How should I proceed?


    First, I'm trying to get the new example to build and stay as true as possible to the article referenced and I'm getting the ord137 error. I can work through it, which will likely get me back to the place which I originally posted about. I will continue to try and diagnose why this is happening. Update: I solved the build issue but the project has deviated significantly from the sample project.

    Second, when/if I do succeed I will likely get the same error I posted about, the flash/slot issue which I suspect is due to partitions expected but not created. This might be do to dynamic partitioning, which seems to be handled in the example project, but not mine for some reason. Update: I am getting the same error:




    And the error:

    Partitions defined by dynamic partitioning:

    I got the 2nd project to build by adding this in the mcuboot.conf:

    CONFIG_GPIO=y
    CONFIG_FLASH=y
    CONFIG_MULTITHREADING=y
    
    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=n

    Now my mcuboot.conf looks like this:

    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_BOOT_MAX_IMG_SECTORS=256
    
    
    CONFIG_GPIO=y
    CONFIG_FLASH=y
    CONFIG_MULTITHREADING=y
    
    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=n
    
    
    CONFIG_SPI=y
    CONFIG_SPI_NOR=y
    CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
    # QSPI drivers are enabled by defualt for some chips.
    # Disable it explicitly to be sure QSPI is disabled.
    CONFIG_NORDIC_QSPI_NOR=n 
    CONFIG_FLASH_JESD216_API=y
    CONFIG_SPI_NOR_SFDP_RUNTIME=y

    Maybe some of it is not needed but this looks very different from the example project which has:

    # Step 6.2 - MCUboot should use external flash
    CONFIG_NORDIC_QSPI_NOR=y
    CONFIG_BOOT_MAX_IMG_SECTORS=256

Reply
  • Any update on this? How should I proceed?


    First, I'm trying to get the new example to build and stay as true as possible to the article referenced and I'm getting the ord137 error. I can work through it, which will likely get me back to the place which I originally posted about. I will continue to try and diagnose why this is happening. Update: I solved the build issue but the project has deviated significantly from the sample project.

    Second, when/if I do succeed I will likely get the same error I posted about, the flash/slot issue which I suspect is due to partitions expected but not created. This might be do to dynamic partitioning, which seems to be handled in the example project, but not mine for some reason. Update: I am getting the same error:




    And the error:

    Partitions defined by dynamic partitioning:

    I got the 2nd project to build by adding this in the mcuboot.conf:

    CONFIG_GPIO=y
    CONFIG_FLASH=y
    CONFIG_MULTITHREADING=y
    
    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=n

    Now my mcuboot.conf looks like this:

    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_BOOT_MAX_IMG_SECTORS=256
    
    
    CONFIG_GPIO=y
    CONFIG_FLASH=y
    CONFIG_MULTITHREADING=y
    
    CONFIG_NORDIC_QSPI_NOR=n
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=n
    
    
    CONFIG_SPI=y
    CONFIG_SPI_NOR=y
    CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
    # QSPI drivers are enabled by defualt for some chips.
    # Disable it explicitly to be sure QSPI is disabled.
    CONFIG_NORDIC_QSPI_NOR=n 
    CONFIG_FLASH_JESD216_API=y
    CONFIG_SPI_NOR_SFDP_RUNTIME=y

    Maybe some of it is not needed but this looks very different from the example project which has:

    # Step 6.2 - MCUboot should use external flash
    CONFIG_NORDIC_QSPI_NOR=y
    CONFIG_BOOT_MAX_IMG_SECTORS=256

Children
  • Hi,

    lcj said:
    I'm not sure what gets the error. Does MCUBoot build first?

    Normally the application is bilt forst, then MCUboot, and lastly nsib/b0 if using secure boot. But this can be seen from the build log where you see the path.

    lcj said:
    Update: I am getting the same error:

    As you are using a custom baord, it si not unlikely that the issue is in the board files. It could be worth testing the smp_server sample with your custom board, and fixing the board files up to the point where you get that sample runnign to reduce the number of unknowns.

    If that does not help, can you share the whole project and your custom board files (everythign needed to build the project), so that I get a better overview and can test at least building on my end?

  • I have a number of tests working with the sample board for each component (external flash, button, ble, pwm, etc.). I was now trying to layer in mcuboot for FOTA. I thought the best way was with this example. That seemed to be your recommendation as well. Is there something specific about the smp sample that is related to mcuboot? It looks like I've narrowed it down specifically to the slots and the number of partitions. Would stepping back from this be a way to move forward? Is there a theory that something is off with the board file which would impact this issue?

  • Hi,

    The smp_svr sample demonstrate DFU via MCUboot, so this is a workign sample that handles that part. Honestly a problem with the board files (and memory and choises and memory paritioning there) is mostly a gut feeling based on things I have seen before, but given the ammount of inormation in this thread I think it would make sense to try to narrow down the issue, and this is may be a way to do that. Most likely this will reinforce your findings.

    (But again, the ammount of information here is high so after that test it would be easier for me to provide input if I get the files so that I can test on my end)

  • Ok. I will give it a shot. We are essentially back to the first post I had. I think it's partitioning, since the error happens in get_flash_area_from_id, but I'm not managing the partitioning (except for specifying the littlefs size) because I'm using dynamic partitioning (as recommened by one of your engineers who I trust).

  • I read this post MCUboot warnings + app errors when using external flash which said:


    I think I "fixed" external flash set up by adding
    CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y
    (I added it in both prj.conf and in bootloader overlay config)


    I did have it in the prj.conf but needed to add it to the mcuboot.conf. This got me through the get_flash_area_from_id error, but I ran into an "Unable to find bootable image" error:

    which seems to happen in the boot_validate_slot call:

Related