nRF9160 enabling mcuboot in v2.4.0 causes SD card on SPI3 to stop working (SPI3 conflict?)

Device being used is an nRF9160 (Circuit Dojo nRF9160 Feather to be exact).

Development platform is MacOS (2015 MacBook Pro 15", Intel) with macOS Ventura v13.5 installed.

The toolchains were installed with nRFconnect through the toolchain installer.

 

I have been troubleshooting a change that happened from v2.3.0 to v2.4.0.

When adding the following option to prj.conf the SD card (which worked in v2.3.0) no longer works.

CONFIG_BOOTLOADER_MCUBOOT=y

I have been troubleshooting this since yesterday and finally traced it down to a change in v2.4.0 (currently using v2.4.1, but same applies).

It appears that the following is now enabled by default in the mcuboot .config file and is in a way conflicting with the SPI3 used for the SD card.

Please confirm, has this been changed and I did not notice it in a changelog?

CONFIG_SPI_NOR=y

Here is the workaround that I have come up with.

create "child_image" in the project folder.

Add the file "mcuboot.conf" into this above folder with the following contents.

Be sure to completely delete the "build" folder (rm -rf build) to force a full rebuild.

CONFIG_SPI_NOR=n

The SD card now can be accessed.

Can this be confirmed a proper work around?  What other implications are there for disabling SPI_NOR in the mcuboot?

I was under the impression that after mcuboot verified the image to boot then control was passed to the application image and no parts of mcuboot would be consuming any resources.

If mcuboot does not behave this way, is there a way that I can share SPI3 so that I do not lose the SPI_NOR functionality? I assume it is for FOTA updates, which I am interested in adding soon.

Below is the configuration for spi3 if it helps... I am still new to pinctrl so please advise if I there are any recommendations to the below pinctrl configuration. The SD card CS line is on GPIO 18.

&spi3 {
        compatible = "nordic,nrf-spim";
        status = "okay";
        cs-gpios = < &gpio0 18 GPIO_ACTIVE_LOW >;
        pinctrl-0 = <&spi3_default>;
        pinctrl-1 = <&spi3_sleep>;
        pinctrl-names = "default", "sleep";
        w25q32jv: w25q32jv@0 {
                compatible = "jedec,spi-nor";
                reg = < 0 >;
                spi-max-frequency = < 40000000 >;
                wp-gpios = < &gpio0 8 GPIO_ACTIVE_LOW >;
                hold-gpios = < &gpio0 10 GPIO_ACTIVE_LOW >;
                size = < 0x2000000 >;
                has-dpd;
                t-enter-dpd = < 3000 >;
                t-exit-dpd = < 30000 >;
                jedec-id = [ ef 40 16  ];
        };
        sdhc0: sdhc@0 {
                compatible = "zephyr,sdhc-spi-slot";
                reg = <0>;
                status = "okay";
                mmc {
                    compatible = "zephyr,sdmmc-disk";
                    status = "okay";
                };
                spi-max-frequency = <24000000>;
        };
};

&pinctrl {
        spi3_default: spi3_default {
                group1 {
                        psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
                                <NRF_PSEL(SPIM_MOSI, 0, 21)>,
                                <NRF_PSEL(SPIM_MISO, 0, 22)>;
                };
        };

        spi3_sleep: spi3_sleep {
                group1 {
                        psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
                                <NRF_PSEL(SPIM_MOSI, 0, 21)>,
                                <NRF_PSEL(SPIM_MISO, 0, 22)>;
                        low-power-enable;
                };
        };
};

Any suggestions or comments would be appreciated.

While browsing the forums I noticed a few others having issues with SD cards, if mcuboot is being used it may be related.

Some information was also helpful to alter the behavior of mcuboot.

 SDHC issues - differences between NCS Zephyr and Downstream Zephyr? 

 RE: SDHC SPI Send Command 

 CONFIG_BOOTLOADER_MCUBOOT costing hundreds of uA? 

 Using a configuration file with mcuboot 

Thank you for taking the time to look into this.

  • Hello, 

    This is a known "bug" due to compatible = "jedec,spi-nor" in the the devicetree, which will automatically includes the SPI_NOR. However, the SPI driver depends on MULTITHREADING, but this is not enabled by default in mcuboot. 

    In the mcuboot part of your build log you'll find this warning, which is what makes the build fail in the end:

    CMake Warning at C:/ncs/v2.4.0/zephyr/CMakeLists.txt:838 (message):
    No SOURCES given to Zephyr library: drivers__spi

    Excluding target from build.

    Can this be confirmed a proper work around?  What other implications are there for disabling SPI_NOR in the mcuboot?

    This is the confirmed work around from our developers, you can also do

    west build -b circuitdojo_feather_nrf9160_ns -- -Dmcuboot_CONFIG_SPI_NOR=n

    Any suggestions or comments would be appreciated.

    Have a look at how this is handled in our Asset Tracker application under nrf\applications\asset_tracker_v2\child_image\mcuboot\boards

    Kind regards,
    Øyvind

  • Hi Øyvind,

    Thanks for the quick reply.  This is kind of the conclusion that I came up with.

    I will look forward to a fix in a later version, for now the -Dmcuboot_CONFIG_SPI_NOR=n will allow development to continue.

    Allan

Related