9160 MCUBoot external flash second slot

Hi,

Since you're referencing a thread for using external flash + mcuboot, I assume that you want to place the secondary slot on ext-flash.

These two lines indicate that mcuboot has issues accessing the correct flash device:

00> NRF_FLASH_DRV_NAME flash dev 0xa0cc
00> [00:00:00.257,781] <wrn> mcuboot: Failed reading sectors; BOOT_MAX_IMG_SECTORS=1024 - too small?

If you look at the project that is linked to in this thread:

 MCUBoot’s secondary image on external flash on nrf9160 - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) 

You want to copy the child_image catalog to your own project (link: https://github.com/simon-iversen/sdk-nrf/tree/d1a11f2c39e3b8fb0af7652e7e720626f0e1298e/samples/nrf9160/http_update/application_update)

In addition, you'd want to create a child_image/mcuboot/boards/$BOARD.overlay file that includes the population of the external flash, for example this section taken from the nrf9160dk_nrf9160 board:

&spi3 {
	status = "okay";
	sck-pin = <13>;
	mosi-pin = <11>;
	miso-pin = <12>;
	cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
	mx25r64: mx25r6435f@0 {
		compatible = "jedec,spi-nor";
		reg = <0>;
		spi-max-frequency = <8000000>;
		label = "MX25R64";
		jedec-id = [c2 28 17];
		sfdp-bfp = [
			e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
			ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
			10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
			30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
		];
		size = <67108864>;
		has-dpd;
		t-enter-dpd = <10000>;
		t-exit-dpd = <35000>;
	};
};

Note that mcuboot runs in the secure region, so if you're using nrf9160dk as a basis, it would be child_image/mcuboot/boards/nrf9160dk_nrf9160.overlay (note the lack of _ns in the naming!)

Could you try the above and see if this works for you? Remember that you should delete and reconfigure your build after making such changes.

Kind regards,

Håkon

user2115 said:

Since you're referencing a thread for using external flash + mcuboot, I assume that you want to place the secondary slot on ext-flash.

Yes, sorry if that was unclear. I just realized I only described that in the title of my ticket. 

user2115 said:

You want to copy the child_image catalog to your own project (link: https://github.com/simon-iversen/sdk-nrf/tree/d1a11f2c39e3b8fb0af7652e7e720626f0e1298e/samples/nrf9160/http_update/application_update)

In addition, you'd want to create a child_image/mcuboot/boards/$BOARD.overlay file that includes the population of the external flash, for example this section taken from the nrf9160dk_nrf9160 board:

I've accomplished this task using a 52820 hooked up to an external flash doing what you described. I'm following the same process of including the child_image directory in my main 9160 application directory and including the secure board overlay file in mcuboot's board directory. 

user2115 said:

Could you try the above and see if this works for you? Remember that you should delete and reconfigure your build after making such changes.

I will verify that I'm doing everything as you described.

While I have you, this is my set up:

/ {
	chosen {
		zephyr,bt-uart=&uart0;
                nordic,pm-ext-flash=&mx25l3;
	};
};

&uart0 {
    current-speed = <115200>;
	/delete-property/ rts-pin;
	/delete-property/ cts-pin;
	/delete-property/ hw-flow-control;
};

&spi3 {
    /* Cannot be used together with i2c0. */
    status = "okay";
    sck-pin = <10>;
    miso-pin = <11>;
    mosi-pin = <12>;
    cs-gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
    mx25l3: mx25l3233f@0 {
        compatible = "jedec,spi-nor";
        reg = <0>;
        spi-max-frequency = <8000000>;
        label = "MX25L3";
        jedec-id = [c2 20 16];
        sfdp-bfp = [
            e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
            ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
            10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
            30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
        ];
        size = <33554432>;
        has-dpd;
        t-enter-dpd = <10000>;
        t-exit-dpd = <100000>;
    };
};

Custom board overlay _ns in main app boards directory and not _ns in mcuboot boards directory

CONFIG_SPI=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_SPI_NOR=y
# using 4MB ext flash
CONFIG_BOOT_MAX_IMG_SECTORS=1024

Settings in both applications prj.conf files

Something of note: the external flash is powered by a voltage regulator which is controlled by the 9160. In my main application, I turn this voltage regulator on in our initialization process in order to communicate with the external flash. I knew that this could pose an issue with this process, so I had to modify MCUBoot's main function to set the pin high and turn on the regulator so that the external flash is powered and MCUBoot can communicate with it. Is there an earlier point that I should do this at or is this sufficient?

Edit: After some more experimenting, my application boots fine if I don't include a pm_static YAML file and just use the one generated by the build system. It is interesting though how that works and I'd appreciate some insight into the difference between these files. I still don't think saving the second copy of the application to the external flash will work however since there is no partitioned size for it in the generated partitions file.

external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000

pm_static.yaml

app:
  address: 0x1c200
  end_address: 0xfe000
  region: flash_primary
  size: 0xe1e00
external_flash:
  address: 0x0
  end_address: 0x400000
  region: external_flash
  size: 0x400000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    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: 0xfe000
  orig_span: &id001
  - spm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0xfe000
  orig_span: &id002
  - app
  - spm
  region: flash_primary
  size: 0xf1e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0x0
  placement:
    align:
      start: 0x4
  region: external_flash
  size: 0x0
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - spm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x2000
spm:
  address: 0xc200
  end_address: 0x1c200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x10000
spm_sram:
  address: 0x20000000
  end_address: 0x20010000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id005
  - spm_sram
  region: sram_primary
  size: 0x10000
  span: *id005

generated partitions.yaml

Hi,

In your mcuboot configuration (ie. child_image/mcuboot.conf or child_image/mcuboot/boards/my_board.conf), you should also define the page size of your external flash:

CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

esisk said:

Something of note: the external flash is powered by a voltage regulator which is controlled by the 9160. In my main application, I turn this voltage regulator on in our initialization process in order to communicate with the external flash. I knew that this could pose an issue with this process, so I had to modify MCUBoot's main function to set the pin high and turn on the regulator so that the external flash is powered and MCUBoot can communicate with it. Is there an earlier point that I should do this at or is this sufficient?

The flash must be enabled and turned on prior to the spi_nor subsys is being enabled.

One way to do this is to use the regulators feature of zephyr:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/reference/peripherals/regulators.html

Here's an example of the setup and usage of this feature:

https://github.com/nrfconnect/sdk-zephyr/blob/v2.6.99-ncs1/boards/arm/thingy52_nrf52832/thingy52_nrf52832.dts#L69-L75

esisk said:

Edit: After some more experimenting, my application boots fine if I don't include a pm_static YAML file and just use the one generated by the build system. It is interesting though how that works and I'd appreciate some insight into the difference between these files. I still don't think saving the second copy of the application to the external flash will work however since there is no partitioned size for it in the generated partitions file.

Yes, your generated partitions.yml does not set a proper size for the secondary partition.

What you can do is to copy the generated partitions.yml to your pm_static.yml, and then replace the "mcuboot_secondary" label with the correct address layout. 

Kind regards,

Håkon

Hey Håkon,

I'm still receiving the same error. I iterated on your feedback so here's the update on my project.

user2115 said:

In your mcuboot configuration (ie. child_image/mcuboot.conf or child_image/mcuboot/boards/my_board.conf), you should also define the page size of your external flash:

Got it. This is my {board_name}.conf file in child_image/mcuboot/boards:

CONFIG_SPI=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_SPI_NOR=y
# using 4MB ext flash
CONFIG_BOOT_MAX_IMG_SECTORS=1024
CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

user2115 said:

The flash must be enabled and turned on prior to the spi_nor subsys is being enabled.

That makes sense. I followed the template on GitHub that you shared and updated both of my board file overlays (non-secure and secure) to include a voltage regulator node. Both overlays are the same:

/ {
	chosen {
		zephyr,bt-uart=&uart0;
        nordic,pm-ext-flash=&mx25l3;
	};

	vdd_pwr: vdd-pwr-ctrl {
		compatible = "regulator-fixed-sync";
		label = "vdd-pwr-ctrl";
		regulator-name = "vdd-pwr-ctrl";
		enable-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
		regulator-boot-on;
	};
};

&uart0 {
    current-speed = <115200>;
	/delete-property/ rts-pin;
	/delete-property/ cts-pin;
	/delete-property/ hw-flow-control;
};

&spi3 {
    /* Cannot be used together with i2c0. */
    status = "okay";
    sck-pin = <10>;
    miso-pin = <11>;
    mosi-pin = <12>;
    cs-gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
    mx25l3: mx25l3233f@0 {
        compatible = "jedec,spi-nor";
        reg = <0>;
        spi-max-frequency = <8000000>;
        label = "MX25L3";
        jedec-id = [c2 20 16];
        sfdp-bfp = [
            e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
            ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
            10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
            30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
        ];
        size = <33554432>;
        has-dpd;
        t-enter-dpd = <10000>;
        t-exit-dpd = <100000>;
		vin-supply = <&vdd_pwr>;
    };
};

I'm new to using the regulator API so I may have set something up incorrectly. I am almost positive that the flash not being enabled before the the spi_nor subsys is enabled is my root issue. Thought this would have been the fix but I had no luck with setting it up and would appreciate any more guidance you could provide. 

user2115 said:

What you can do is to copy the generated partitions.yml to your pm_static.yml, and then replace the "mcuboot_secondary" label with the correct address layout.

From what I've read, this shouldn't have an effect on the spi_nor subsys communicating with the external flash, but here's my pm_static.yml:

external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000

For some reason I can't edit my previous response so I'm replying here. Anyway, I actually got the application to boot. Once I set

CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED=y

in my {board_name}.conf file, the application booted fine. After that, I encountered another error where the fota_download initialization failed due to 

<err> dfu_target_mcuboot: Failed to get device 'MX25L3'

I figured that it was failing because the spi_nor driver was not being enabled in my non-secure application. Once I copied the same configuration variables from my {board_name}.conf file used for MCUBoot into a {board_name_ns}.conf file, the library initialized successfully and I could remotely update the application. I'll continue to test but my understanding of setting this all has improved and the cryptic root issue I was having has been found. I'd appreciate it Håkon if you could explain to me the difference between a {board_name}.conf file and the normal prj.conf file?