This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

9160 MCUBoot external flash second slot

I've been referencing these two tickets pretty closely How to specify signing the key with MCUBoot - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) and MCUBoot’s secondary image on external flash on nrf9160 - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) to accomplish this task. I'm using NCS v1.7.0 on a custom board. I still run into errors when MCUBoot is running (I modified MCUBoot slightly but was experiencing the issue before this): 

*** Booting Zephyr OS build v2.6.99-ncs1  ***
00> 
00> gpio_dev 0xa0b4 setting pin 4 high
00> 
00> [00:00:00.257,476] <inf> mcuboot: Starting bootloader
00> NRF_FLASH_DRV_NAME flash dev 0xa0cc
00> 
00> [00:00:00.257,781] <wrn> mcuboot: Failed reading sectors; BOOT_MAX_IMG_SECTORS=1024 - too small?
00> [00:00:00.257,812] <err> os: ***** MPU FAULT *****
00> [00:00:00.257,812] <err> os:   Instruction Access Violation
00> [00:00:00.257,843] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x2001497c[0m
00> [00:00:00.257,843] <err> os: r3/a4:  0x00000020 r12/ip:  0xfef7f9b5 r14/lr:  0x00000f6b
00> [00:00:00.257,843] <err> os:  xpsr:  0x69100000
00> [00:00:00.257,873] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
00> [00:00:00.257,873] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
00> [00:00:00.257,873] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
00> [00:00:00.257,904] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
00> [00:00:00.257,904] <err> os: fpscr:  0x0000a0cc
00> [00:00:00.257,904] <err> os: Faulting instruction address (r15/pc): 0xfef7f9b4
00> [00:00:00.257,904] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:00.257,904] <err> os: Current thread: 0x20014880 (unknown)
00> [00:00:00.808,502] <err> fatal_error: Resetting system
00> [00:00:00.252,288] <err> spi_nor: Device id 00 00 00 does not match config c2 20 16

I've triple checked everything and I've yet to make any progress. Are there any known issues surrounding what I'm trying to attempt? I saw https://github.com/nrfconnect/sdk-mcuboot/pull/200 in the second ticket; however after reading the PR it seems to be a non-issue.

Parents
  • 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:

    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

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

    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. 

    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.

    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

    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. 

    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

Reply
  • Hey Håkon,

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

    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

    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. 

    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

Children
No Data
Related