Flash area error when attempting DFU via nRF Connect App

Hello,

I'm getting the following error  when attempting to perform a DFU. I'm using the Android nRF Connect app.

00> I: Image index: 0, Swap type: test
00> I: Image index: 1, Swap type: none
00> E: Failed to open flash area ID 1: -2

Flash Area ID of 1 indicates it's external flash. Error -2 is ENOENT. So it's saying that no such flash area exists? I suspect something is not configured correctly.

Here is my external flash devicetree snippet:

&spi4 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	pinctrl-0 = <&spi4_default>;
	pinctrl-1 = <&spi4_sleep>;
	pinctrl-names = "default", "sleep";
	cs-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;

	sst26vf: sst26vf064b@0 {
		compatible = "jedec,spi-nor";
				reg = <0>;
		spi-max-frequency = <24000000>;
		jedec-id = [bf 26 43]; /* see datasheet table 5-4, p.25 */

		/* see datasheet pp. 72-79 for basic flash parameters table below */
		sfdp-bfp = [
			fd 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 80 bb
			fe ff ff ff  ff ff 00 ff  ff ff 44 0b  0c 20 0d d8
			0f d8 10 d8  20 91 48 24  80 6f 1d 81  ed 0f 77 38
			30 b0 30 b0  f7 ff ff ff  29 c2 5f ff  f0 30 c0 80
		];
		size = <67108864>;

	 	requires-ulbpr; /* sst26vf has block write protections enabled by default */
	};
};

The project is based on the smart lock sample code. I had to increase the size of the bootloader region to get it to fit. Here is the pm_static_dfu.yml file:

mcuboot:
  address: 0x0
  size: 0xc000
  region: flash_primary
mcuboot_pad:
  address: 0xc000
  size: 0x200
app:
  address: 0xc200
  size: 0xeae00
mcuboot_primary:
  orig_span: &id001
  - mcuboot_pad
  - app
  span: *id001
  address: 0xc000
  size: 0xeb000
  region: flash_primary
mcuboot_primary_app:
  orig_span: &id002
  - app
  span: *id002
  address: 0xc200
  size: 0xeae00
factory_data:
  address: 0xf7000
  size: 0x1000
  region: flash_primary
settings_storage:
  address: 0xf8000
  size: 0x8000
  region: flash_primary
mcuboot_primary_1:
  address: 0x0
  size: 0x40000
  device: flash_ctrl
  region: ram_flash
mcuboot_secondary:
  address: 0x0
  size: 0xef000
  device: SST26VF
  region: external_flash
mcuboot_secondary_1:
  address: 0xef000
  size: 0x40000
  device: SST26VF
  region: external_flash
external_flash:
  address: 0x12f000
  size: 0x6D1000
  device: SST26VF
  region: external_flash
pcd_sram:
  address: 0x20000000
  size: 0x2000
  region: sram_primary

I'm don't know how or if this yaml file relates to the partitions defined in the devicetree, but here are the devicetree partitions:

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x00010000>;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
		};
		slot0_ns_partition: partition@50000 {
			label = "image-0-nonsecure";
		};
		slot1_partition: partition@80000 {
			label = "image-1";
		};
		slot1_ns_partition: partition@c0000 {
			label = "image-1-nonsecure";
		};
		/* 0xf0000 to 0xf7fff reserved for TF-M partitions */
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0x000f8000 0x00008000>;
		};
	};
}

Thanks.

Parents
  • Hello,

    Could you have a look at this sample for testing the external flash? Try to run this sample and see if the external flash works fine. There is also an unofficial sample from my colleague that deals with external flash. Try testing these samples and see if the external flash works fine.

    I would also recommend checking the memory report-->Partition manager to see if the partitioning was performed as expected. See this ticket.

    Kind Regards,

    Abhijith

  • Thanks for the response.

    I'm not ruling out the external flash. But what I'd like to do first is get the software working correctly on known good hardware. In my case, that is the nRF5340-DK.

    I'm using the "matter lock" sample project.

    I've made the following additions to prj.conf:

    CONFIG_CHIP_OTA_REQUESTOR=y
    CONFIG_CHIP_DFU_OVER_BT_SMP=y
    CONFIG_LOG_DEFAULT_LEVEL=3

    Everything else is left as-is.

    Using this, when I try a DFU using the nRF Connect Android app, I get the following errors from the DK:

    I: Secondary image of image pair (0.) is unreachable. Treat it as empty
    I: Image index: 0, Swap type: none
    E: Failed to open flash area ID 2: -19
    I: Secondary image of image pair (1.) is unreachable. Treat it as empty
    I: Image index: 1, Swap type: none
    E: Failed to open flash area ID 1: -2
    E: Failed to open flash area ID 8: -19
    I: Secondary image of image pair (1.) is unreachable. Treat it as empty
    I: Image index: 1, Swap type: none
    E: Failed to open flash area ID 8: -19
    E: Image upload inspect failed: 10
    E: Failed to open flash area ID 2: -19
    

    So, mixtures of ENOENT and ENODEV.

    Is this something that's supported? Is there any other configuration needed to get this working with the DK board?

Reply
  • Thanks for the response.

    I'm not ruling out the external flash. But what I'd like to do first is get the software working correctly on known good hardware. In my case, that is the nRF5340-DK.

    I'm using the "matter lock" sample project.

    I've made the following additions to prj.conf:

    CONFIG_CHIP_OTA_REQUESTOR=y
    CONFIG_CHIP_DFU_OVER_BT_SMP=y
    CONFIG_LOG_DEFAULT_LEVEL=3

    Everything else is left as-is.

    Using this, when I try a DFU using the nRF Connect Android app, I get the following errors from the DK:

    I: Secondary image of image pair (0.) is unreachable. Treat it as empty
    I: Image index: 0, Swap type: none
    E: Failed to open flash area ID 2: -19
    I: Secondary image of image pair (1.) is unreachable. Treat it as empty
    I: Image index: 1, Swap type: none
    E: Failed to open flash area ID 1: -2
    E: Failed to open flash area ID 8: -19
    I: Secondary image of image pair (1.) is unreachable. Treat it as empty
    I: Image index: 1, Swap type: none
    E: Failed to open flash area ID 8: -19
    E: Image upload inspect failed: 10
    E: Failed to open flash area ID 2: -19
    

    So, mixtures of ENOENT and ENODEV.

    Is this something that's supported? Is there any other configuration needed to get this working with the DK board?

Children
  • Hello,

    Luis said:
    I'm not ruling out the external flash. But what I'd like to do first is get the software working correctly on known good hardware. In my case, that is the nRF5340-DK.

    Could you clarify a few things? Are you able to do a BLE DFU with internal flash? If you haven't tried that, I recommend doing so.

    Try the nRF5340 bootloader samples, and then try the external flash sample; this will help narrow down where the error is.

    Luis said:
    Using this, when I try a DFU using the nRF Connect Android app, I get the following errors from the DK

    Is this the complete log? If not, could you share the whole log?

    Are you trying to do a device firmware upgrade over matter?

    Kind Regards,

    Abhijith

  • Hi Abhijith,

    I tried running the supplied nRF5340 bootloader samples, but got the following errors on bootup:

    I: Starting bootloader
    W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
    W: Cannot upgrade: slots are not compatible
    W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
    W: Cannot upgrade: slots are not compatible
    I: Bootloader chainload address offset: 0xc000
    [00:00:00.000,732] <err> qspi_nor: JEDEC id [00 00 00] expect [c2 28 17]
    *** Booting nRF Connect SDK v2.5.99-dev1 ***
    Change this to see it change.
    [00:00:00.029,602] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
    [00:00:00.029,632] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
    [00:00:00.029,663] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 161.54902 Build 901303921
    [00:00:00.031,250] <inf> bt_hci_core: Identity: C5:E1:A2:57:DC:F1 (random)
    [00:00:00.031,280] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x211a, manufacturer 0x0059
    [00:00:00.031,280] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x211a
    Bluetooth initialized
    Advertising successfully started
    

    This is running on the nRF5340-DK board. I tried two different boards, each had the same result.

    Have you tried running this on the DK board? Was it written to run on different hardware? I'm not aware of anything preventing external flash from identifying correctly. I haven't touched any of the solder bridges (SB10-15, nor SB20-25).

Related