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

[lcj]

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

[lcj]

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

[Einar Thorsrud]

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?

[lcj]

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?

[Einar Thorsrud]

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)

[lcj]

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