External flash stops working after enabling MCUboot

[kentorth]

I am doing some development where I use the external flash for storage external to my application.  When I enable MCUboot, I can no longer access the external flash.  This is on an nrf52840.  Pretty new to Zephyr, so I think I've got my overlay configured correctly.  flash0 looks to be all on the mcu flash partitions, so unsure at the moment why I can't access the external flash.  If I disable MCUboot, I can access external flash again.

Any help is appreciated.

Thanks

[Hung Bui]

Hi Kenny, 
Could you show how you access the external flash ? 
Also please show the partition configuration (pm_static.yml or the partitions.yml in the build folder) . Usually the partitions configuration will show how the mcuboot occupy the flash/external flash. 

Which error do you see when you try to access the flash ? 

[kentorth]

Hi Hung,

Thanks for the prompt reply.  I implemented a command line to direct access the flash functions, using SPI transfers.  I started with the nrf52840dk and now working with a custom board so I have an overlay.  I am currently using it in standard x1, rather than quad.

My overlay defines SPI config as follows:

spi2_default: spi2_default {

        group1 {

            psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,

                <NRF_PSEL(SPIM_MOSI, 0, 23)>,

                <NRF_PSEL(SPIM_MISO, 1, 00)>;

        };

    };

spi2: &spi2 {

    compatible = "nordic,nrf-spim";

    status = "okay";

    pinctrl-0 = <&spi2_default>;

    pinctrl-1 = <&spi2_sleep>;

    pinctrl-names = "default", "sleep";

    cs-gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;

    w25q64: w25q64@0 {

        compatible = "jedec,spi-nor";

        label = "W25Q64";

        reg = < 0 >;

        spi-max-frequency = < 40000000 >;

        wp-gpios = < &gpio0 22 GPIO_ACTIVE_LOW >;

        hold-gpios = < &gpio0 21 GPIO_ACTIVE_LOW >;

        size = < 0x1000000 >;

        has-dpd;

        t-enter-dpd = < 3000 >;

        t-exit-dpd = < 30000 >;

        jedec-id = [ ef 40 16  ];

    };

};

The command line functions can write and read the flash just fine.  I wanted to tinker with the bootloader, so I added the following, and can no longer read from flash via command line:

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

Here are the partitions.yml contents:

app:

  address: 0xc200

  end_address: 0x86000

  region: flash_primary

  size: 0x79e00

mcuboot:

  address: 0x0

  end_address: 0xc000

  placement:

    before:

    - mcuboot_primary

  region: flash_primary

  size: 0xc000

mcuboot_pad:

  address: 0xc000

  end_address: 0xc200

  placement:

    align:

      start: 0x1000

    before:

    - mcuboot_primary_app

  region: flash_primary

  size: 0x200

mcuboot_primary:

  address: 0xc000

  end_address: 0x86000

  orig_span: &id001

  - app

  - mcuboot_pad

  region: flash_primary

  sharers: 0x1

  size: 0x7a000

  span: *id001

mcuboot_primary_app:

  address: 0xc200

  end_address: 0x86000

  orig_span: &id002

  - app

  region: flash_primary

  size: 0x79e00

  span: *id002

mcuboot_secondary:

  address: 0x86000

  end_address: 0x100000

  placement:

    after:

    - mcuboot_primary

    align:

      start: 0x1000

    align_next: 0x1000

  region: flash_primary

  share_size:

  - mcuboot_primary

  size: 0x7a000

sram_primary:

  address: 0x20000000

  end_address: 0x20040000

  region: sram_primary

  size: 0x40000

Is it possible there's something from the original nrf52840dk dts that's configured using the external flash and I just haven't undefined it in my overlay?

Thanks,

Kenny

[kentorth]

Hi Hung,

Update.  Doing some digging, I don't think it's CONFIG_BOOTLOADER_MCUBOOT=y that is causing the issue but rather CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y causing basic SPI to no longer function.  Then I found this thread:

 CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU doesn't work with SPI NOR 

Looks like a workaround until it gets addressed.  It also looks like CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU is using external flash.  What is the easiest way to configure it for internal flash?

Thanks

[Hung Bui]

Hi Kenny,
Thanks for the info, from what I can see in NCS v2.8.0 the NORDIC_QSPI_NOR imply is removed. Please try to update to the latest NCS. 
From what I can see in the MCUBoot partition you provided, the MCUBoot is using internal flash. 
Please try to check the partitions.yml after build. 

[kentorth]

Hi Hung,

First, my apologies for misreading CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU.  You are correct it is not using external flash unless that config is enabled.

I also should've clarified, I was only able to probe the SPI chip select pin on the custom board as that is the only one with a test point.  I created a dumbed down version of my project where it is a pure SPI read and MCUboot with FOTA to make sure I can reproduce the following issues:

• No MCUboot and FOTA, SPI works.
• Enabling MCUboot and FOTA, SPI stops working.

After reproducing the issue, I updated my toolchain and SDK to v2.8.0.  After upgrading, I had to switch to using sysbuild with SB_CONFIG_BOOTLOADER_MCUBOOT and the issue persisted.  What I realized is once i removed MCUboot and FOTA, and rebuilt/reprogrammed, the SPI (chip select) still was not working.  The SPI (chip select) would not work until I performed an Erase Board.  Then reprogramming worked.

This led me to digging into the Erase Board.  I realized it is also erasing the UICR so I repeated the steps above, skipped the Erase Board and issued an nrfjprog --eraseuicr and performed a soft reset and the SPI (chip select) worked again.

I think the problem I'm seeing was compounded by two issues:

1. CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU made simple SPI stop working (addressed in previous post) but SDK v2.8.0 fixes this.

2. My SPI chip select is on pin P0.18 which defaults to being used for reset.  I need to add the following to my overlay to specify the UICR not program it as a reset.  Once the UICR gets programmed to issue it as a reset, it needs to be cleared by the tools.

&uicr {

    /delete-property/ gpio-as-nreset;

};

Questions I have are:

• Is the bootloader setting UICR for P0.18 as a reset?
• Can I add something in my application to clear this register?

Thanks

[kentorth]

Confirmed using nrfjprog --memrd 0x10001200 that with the MCUboot and FOTA, the PSELRESET registers are getting written to 0x00000012.

I've added a function to erase UICR at the beginning of my application.  I verified by reading back but the chip select is still not registering.  I think I need to reconfigure the SPI peripheral after erasing UICR.  I haven't the slightest clue how to do that with zephyr, so I will probably have to dig into the nrfx libraries and the hardware registers to try that next.  Please let me know if there's an easier fix for this.

Thanks,

Kenny

[Hung Bui]

Hi Kentorth, 
This config is deprecated but maybe you can double check if you have it in your .config in build folders (for application and for MCUBoot). 

CONFIG_GPIO_AS_PINRESET=n 

I think the problem here is that the MCUBoot image doesn't have the overlay to not configure the pin as pin reset. 
&uicr {
/delete-property/ gpio-as-nreset;
};

So what you need to do is to either put the overlay file into MCUBoot\boards folder so that it will be used. 

Or if you use sysbuild, you need to put the overlay into sysbuild\mcuboot\boards and you need to copy the prj.conf (and all other configuration if used) from MCUBoot to sysbuild\mucboot . 
Please take a look at this https://docs.zephyrproject.org/latest/build/sysbuild/index.html#zephyr-application-kconfig-fragment-and-devicetree-overlay

I would suggest to try testing with the first suggestion first.