SDK 2.3.0 - can't disable qspi in DT overlay file?

We have just migrated the software for our custom nrf5340 based board from SDK v1.9.1 to v2.3.0.
Everything seems to be working well but we have one issue with the nrf5340dk_nrf5340_cpuapp.overlay file.

We have two GPIO's (pins 13 & 18) that we use that conflict with the pins assigned to the qspi device pre-configured in the
/nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts file.

One of those custom GPIO's (pin 13) is used to disconnect the battery from the device (!!) and the other is used to switch off power to our i2c peripherals.
We can see that the pre-configured qspi device is defined in exactly the same way in SDK v1.9.1 & v2.3.0 (of course v2.3.0 uses the new pin control format), 
in the /nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts file.

In BOTH SDK's, the qspi is defined with: status = "okay" in that nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts file mentioned above.
So in theory there should be no difference in the way qspi is used (or rather NOT used!) between v1.9.1 & v2.3.0 builds.

In our v1.9.1 overlay file we never referenced the qspi device.  However, when we build with SDK v2.3.0 (after having followed all the migration steps),
we find that two of the GPIO pins we use, (pins 13 & 18) are suddenly oscillating even when we do NOT reference those pins in our code.
Plus all the voltage rails are much noisier (by around 0.3v) indicating contention. We also do not reference or use the qspi device in our code. 

After we investigated/debugged this, we found that this "problem" (in our v2.3.0 build) went away as soon as we disabled the qspi device - which makes sense & is OK. 

HOWEVER, the qspi device can NOT be disabled in the nrf5340dk_nrf5340_cpuapp.overlay file!!?? When we add:

&qspi {
	status = "disabled";
};


it has NO EFFECT and the problem described above (with pins 13 & 18) and the noise on all power rails remains.

So the only way we seem to be able to "get rid of" (= disable!) the qspi device, is to change the status from "okay" to "disabled" in the 
SDK file /nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts

Although this solves our problem, obviously doing it this way is less than ideal (difficult to track/remember when one updates the SDK, etc) & it should be done in the overlay file.

So my question is: Why can the qspi device not be disabled in the SDK v2.3.0 overlay file?
Is this is bug in the v2.3.0 SDK? Or is there another way to do this in our v2.3.0 overlay file?
We also disable a number of other devices (like all uart's, etc) in our v2.3.0 overlay file, so we know the file itself is working and being included in our build.
There are no new warnings in our v2.3.0 build (vs. the v1.9.1 builds).

What is also strange to us is that in the SDK v1.9.1 builds, we didn't even have to disable the qspi device (as we never had that issue with pins 13 & 18 with our v1.9.1 builds).
As I mentioned our hardware design & software NEVER references or uses the qspi device.

Below is our SDK v2.3.0 overlay file:

&pinctrl {
	uart0_default_alt: uart0_default_alt {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 4)>,
				<NRF_PSEL(UART_RTS, 1, 6)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 1, 5)>,
				<NRF_PSEL(UART_CTS, 1, 7)>;
			bias-pull-up;
		};
	};

	uart0_sleep_alt: uart0_sleep_alt {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 4)>,
				<NRF_PSEL(UART_RX, 1, 5)>,
				<NRF_PSEL(UART_RTS, 1, 6)>,
				<NRF_PSEL(UART_CTS, 1, 7)>;
			low-power-enable;
		};
	};
	
	i2c1_default: i2c1_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 1, 2)>,
				<NRF_PSEL(TWIM_SCL, 1, 3)>;
			bias-pull-up;
			nordic,drive-mode = < NRF_DRIVE_S0D1 >;
		};
	};

	i2c1_sleep: i2c1_sleep {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 1, 2)>,
				<NRF_PSEL(TWIM_SCL, 1, 3)>;
			low-power-enable;
		};
	};
};

&adc {
	status = "okay";
};

&gpio0 {
	status = "okay";
};
&gpio1 {
	status = "okay";
};

&gpiote {
	status = "disabled";
};

&qspi {
	status = "disabled";
};

&i2c1 {
	status = "okay";
    accelerometer: accelerometer@5 {
        compatible = "i2c-device";
        reg = < 0x05 >;
        label = "ACCELEROMETER";
    };
	tdksensor: TDKsensor@8 {
        compatible = "i2c-device";
        reg = < 0x08 >;
        label = "TDKSENSOR";
    };
};
&i2c0 {
	status = "disabled";
};
&i2c2 {
	status = "disabled";
};

&uart0 {
	status = "disabled";
    pinctrl-0 = <&uart0_default_alt>;
    pinctrl-1 = <&uart0_sleep_alt>;
    pinctrl-names = "default", "sleep";
};
&uart1 {
	status = "disabled";
};
&uart2 {
	status = "disabled";
};
&uart3 {
	status = "disabled";
};

&led0 {
	status = "disabled";
};
&led1 {
	status = "disabled";
};
&led2 {
	status = "disabled";
};
&led3 {
	status = "disabled";
};

&pwm_led0 {
	status = "disabled";
};

&spi0 {
	status = "disabled";
};
&spi1 {
	status = "disabled";
};
&spi2 {
	status = "disabled";
};
&spi3 {
	status = "disabled";
};
&spi4 {
	status = "disabled";
};

&button0 {
	status = "disabled";
};
&button1 {
	status = "disabled";
};
&button2 {
	status = "disabled";
};
&button3 {
	status = "disabled";
};

&zephyr_udc0 {
    status = "disabled";
	/*
	cdc_acm_uart0: cdc_acm_uart0 {
		compatible = "zephyr,cdc-acm-uart";
		label = "CDC_ACM_0";
	};
	*/
};
/*
/ {
	chosen {
			zephyr,console = &cdc_acm_uart0;
	};
};
*/

Thanks

Gerard
 

Parents
  • Hi,

    That sounds like a bug, and may be related to the switch over to pinctrl.

    Could you try to add this line to your prj.conf file?

    CONFIG_NORDIC_QSPI_NOR=n

    Does that change the behavior of the pins in any way?

  • Hi Oivind

    I just tried your suggestion but unfortunately it also made no difference...! :( 

    So it seems the only way to solve this (so far!) is to disable qspi in 
    /nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts

    Any more ideas..!? Slight smile

    I was thinking that maybe one could redefine the qspi device (using pin control format)  in the overlay file in such a way that it no longer "interferes" (using different - dummy! - PIN numbers). But I'm not sure if that can "safely" be done!?

    So guess the "solution" is to fix the underlying problem/bug in zephyr/SDK v2.3.0 (which will probably take time!). 

    Thanks 

    Gerard

  • You can try changing the pins in the overlay, that is completely safe, but I'm not confident that it will help.

    To try it add these to your overlay and change the pins as you see fit:

    &qspi_default {
    	group1 {
    		psels = <NRF_PSEL(QSPI_SCK, 0, 17)>,
    			<NRF_PSEL(QSPI_IO0, 0, 13)>,
    			<NRF_PSEL(QSPI_IO1, 0, 14)>,
    			<NRF_PSEL(QSPI_IO2, 0, 15)>,
    			<NRF_PSEL(QSPI_IO3, 0, 16)>,
    			<NRF_PSEL(QSPI_CSN, 0, 18)>;
    	};
    };
    
    &qspi_sleep {
    	group1 {
    		psels = <NRF_PSEL(QSPI_SCK, 0, 17)>,
    			<NRF_PSEL(QSPI_IO0, 0, 13)>,
    			<NRF_PSEL(QSPI_IO1, 0, 14)>,
    			<NRF_PSEL(QSPI_IO2, 0, 15)>,
    			<NRF_PSEL(QSPI_IO3, 0, 16)>;
    			low-power-enable;
    	};
    	group2 {
    		psels = <NRF_PSEL(QSPI_CSN, 0, 18)>;
    		low-power-enable;
    		bias-pull-up;
    	};
    };

  • Hi again Øivind

    I had already tried that before I reported this problem - it also doesn't help (as you suspect!).

    What I meant was redefining qspi in overlay using "safe" pins (from our point of view, ie: pins that wouldn't matter if they oscillated!) but as I said it is too risky & difficult to test for side effects!

    Is there any hope that this will get fixed soon..!? Curious.... :) 


    Thanks for your fast response.

    Regards

    Gerard

  • Thanks for this post.
    I just spent two days uncovering this same problem. Once I noticed the pin oscillating I figured it might be qspi config. Then I was able to easily find this post. 

    Maybe there needs to be some kind of notice on the sdk to highlight this issue to save others repeating the same investigation.

  • Hi Justin

    Nice to hear that I am not the only one having this problem - so thanks for the update!

    However, given the fact that the qspi device is defined with status="okay" (so enabled!) in BOTH SDK v1.9.1 and v2.3.0, the BIG (unanswered!) QUESTION for me is actually:

    Why does the qspi driver in SDK v2.3.0 behave this way even when it is never accessed/initialized anywhere in one's code (& yet it seems to be "dormant" in SDK v1.9.1)? 

    Makes we wonder if there are any power consumption (or other!) side-effects...!?

    Curious....! :)

    Gerard 

Reply
  • Hi Justin

    Nice to hear that I am not the only one having this problem - so thanks for the update!

    However, given the fact that the qspi device is defined with status="okay" (so enabled!) in BOTH SDK v1.9.1 and v2.3.0, the BIG (unanswered!) QUESTION for me is actually:

    Why does the qspi driver in SDK v2.3.0 behave this way even when it is never accessed/initialized anywhere in one's code (& yet it seems to be "dormant" in SDK v1.9.1)? 

    Makes we wonder if there are any power consumption (or other!) side-effects...!?

    Curious....! :)

    Gerard 

Children
  • did you solve this problem?
    I'm having the same problem.

  • Hi John,

    Yes - as I said in my original post:

    "So it seems the only way to solve this (so far!) is to disable qspi in 
    /nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts"

    You need to disable qspi in that file of the SDK. Not ideal as you need to do that every time you update your SDK (using nrf Connect Toolchain update). But of course normally one does not update the ToolChain until there is a new version & then you probably should check whether or not this problem has been fixed in the new SDK.

    OK?

  • thank you it helped a lot
    I lost trust in NCS over this issue
    Have you ever had the same problem with other non-qspi peripherals?

  • No - never had the problem with other peripherals - normal you can (& should!) disable them in the DT overlay.

    I have been working with nrf Connect for Desktop for a more than 1 year now. This seems a bug in SDK v2,3,0 but I never heard if they fixed it (or are looming into it).

    In SDK v1.9.1 I never had this problem.

    Regards

    Gerard 

  • Hi all,

    I will continue to help in this case.

    Is this a bug?
    No, I do not think so.
    I think the confusion is because multi-image builds are complicated.
    If it during my explanation below turns out I am wrong, let me know.

    After reading the case, this is what I think your problem is
    QSPI is not completely disabled in your project, even though you (thought) you disabled it.

    How to fix this
    As Gerard said: You disable the QSPI in the board files.
    However, I will disagree that you need to update this in every nRF Connect SDK update.
    Either create new board files for your custom board, or use child image configuration to configure your board.
    Both solutions explained below.

    How to fix this with custom board
    You will (hopefully) create your own PCB and not sell DKs directly as your end products.
    If you do this you will eventually have to create custom board files in the nRF Connect SDK.
    I would argue that when you want develop a project for the DK with large changes (such as removing the QSPI drivers), you should create a custom board instead of using the dk board files.
    If you do this, your new board files will be out-of-tree, aka not a part of the nRF Connect SDK, and therefore not need to be changed back on every nRF Connect SDK update.
    With custom board files, the child images such as b0 and mcuboot will inherit board configurations such as disabled QSPI.

    How to fix this with child image overlay

    If you still want to use the DK board files for development, you can still do so.
    Since child images will inherit board file configurations, and will not inherit configurations from the main image, you must configure the application and each child image manually. See multi-image builds for how to do this.
    For an application with b0 and mcuboot, the folder structure could for one example configuration look something like this:

    ├── app.overlay
    ├── child_image
    │   ├── b0.conf
    │   ├── b0.overlay
    │   ├── mcuboot.conf
    │   └── mcuboot.overlay
    ├── CMakeLists.txt
    ├── prj.conf
    ├── README.rst
    ├── sample.yaml
    └── src
        └── main.c
    

    Then you would have to add your global configurations to all three .conf and .overlay files.

    Conclusion

    Did I understand the issue correctly?
    If my fixes does not work, let me know.
    Also, if you got any questions to this, let me know.

    Regards,
    Sigurd Hellesvik

Related