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

[kentorth]

Tested and confirmed working.  Thank you for your help.