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

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

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

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

Related