SAADC - Scan mode connects inputs to VDD_GPIO?

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Tue, 22 Nov 2022 14:34:33 GMT

Yeah, pristine build in all cases. Build configuration was always the same, though.
I created a new build configuration, and tried moving the overlay to the project root folder (same as prj.conf). Previously it was in <project_root>/boards.

No change, P0.14 is still output, P0.10 and P0.11 unchanged.

If I change the entry in nrf9160_nrf9160_common-pinctrl.dtsi I no longer see the P14 VDD_GPIO spikes using the oscilloscope. So yes, to answer your question is is the P0.14 and P0.15, related to uart1 that is causing my SAADC issues.

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Øivind — Tue, 22 Nov 2022 12:42:56 GMT

Hm, are you doing pristine builds? Try deleting the build configuration / build folder and have the change only in the overlay. I assume you are targeting the nrf9160dk_nrf9160_ns board, so the overlay name is correct. Can you try putting the overlay in the project folder, next to prj.conf?

And when you change the uart1 pins in pinctrl, does the SAADC work properly with the P0.14 and P0.15 pins? So we can confirm that it was causing issues, despite uart1 being disabled?

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Mon, 21 Nov 2022 14:52:18 GMT

Hi, adding that to the project overlay file, no effect for any PIN_CNF's for 10, 11, 14 or 15

Overlay is included in the build and the other changes (gpio inputs/outputs, aliases and I2C devices) are used in the binary.
However, when I tried changing the pins in nrf9160_nrf9160_common-pinctrl.dtsi it worked as expected, 10=output, 11=input with pull-up, 14 and 15 were inputs with everything disabled.

Is it possible the overlay isn't working as we're building for nonsecure while the TFM configuration is done for the secure target?

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Øivind — Mon, 21 Nov 2022 12:08:56 GMT

Hi,

Could you add this to your overlay file? It's just to check whether these pins being defined in the pinctrl node is causing issues despite the uart1 node being disabled. If you get an error when building, try some other unused pins for the RTS and CTS.

&pinctrl {
    uart1_default: uart1_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 1)>,
				<NRF_PSEL(UART_RTS, 1, 10)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 0)>,
				<NRF_PSEL(UART_CTS, 1, 11)>;
			bias-pull-up;
		};
	};

	uart1_sleep: uart1_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 1)>,
				<NRF_PSEL(UART_RX, 0, 0)>,
				<NRF_PSEL(UART_RTS, 1, 10)>,
				<NRF_PSEL(UART_CTS, 1, 11)>;
			low-power-enable;
		};
	};
};

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Thu, 17 Nov 2022 07:41:58 GMT

Hovering says "n" when compiled with TFM_LOG_LEVEL_SILENCE=y.

Output .config -file contains:

CONFIG_TFM_BOARD="C:/Tools/ncs/v2.0.2/nrf/modules/tfm/tfm/boards/nrf9160"
# CONFIG_TFM_SECURE_UART1 is not set

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Karl Ylvisaker — Mon, 14 Nov 2022 12:41:53 GMT

Hello again,

Thank you for your patience with this.

I have looked further into this and discussed it with some colleagues, and we found this part about the TF-M logging.

The default value should be adjusted based on the SILENCE config, but it does not seem to be the case with your application.

The config for the logging directly reads:

config TFM_SECURE_UART1
    bool "TF-M configure UART1 as secure peripheral"
    default y if !TFM_LOG_LEVEL_SILENCE
    depends on !UART_1_NRF_UARTE
    depends on !"$(dt_nodelabel_enabled,uart1)"
    depends on SOC_NRF5340_CPUAPP || SOC_NRF9160
    help
      Configure the UART1 peripheral as secure for TF-M logging.
      This makes the UART1 peripheral unavailable to the non-secure
      application. When this option is selected the device tree node for
      UART1 needs to be disabled for the non-secure application.

Is this currently enabled in your build (despite the SILENCE config)? You can check this by writing TFM_SECURE_UART1 in your prj.conf and hoovering over it with your mouse, for instance.

Best regards,
Karl

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Mon, 07 Nov 2022 07:36:57 GMT

TFM_LOG_LEVEL_SILENCE=y had no effect. Here's a screenshot of the PIN_CNF registers, pins 14 and 15 are the ones which get configured differently so you are probably correct that it's UART1 related (though it is indeed disabled as seen while debugging registers):

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Karl Ylvisaker — Wed, 02 Nov 2022 12:46:19 GMT

Alright, great - no worries about the time, we'll continue this whenever you have the chance.
If the behavior you are seeing changes with the inclusion of the TFM log disable while the compiled devicetree stays the same I'll create another minimal example to try and replicate and explain the behavior.

Best regards,
Karl

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Wed, 02 Nov 2022 06:13:16 GMT

Hi,

I'll test it when I have the time and report back.

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Karl Ylvisaker — Tue, 01 Nov 2022 12:49:25 GMT

That's peculiar.. does the behavior of the pin change if you add TFM_LOG_LEVEL_SILENCE=y in your prj.conf?
Based on the compiled devicetree I would not expect so, but I ask just so that we can rule it out.

Best regards,
Karl

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Mon, 31 Oct 2022 14:02:46 GMT

The compiled devicetree shows uart1 as "disabled". All references to UART1 in the compiled devicetree are shown in the post above yours.

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Karl Ylvisaker — Mon, 31 Oct 2022 13:53:02 GMT

Hello again,

Thank you for your patience with this.
Since you are building for Non-secure, you will have TF-M added, which in turn uses UART1 for logging from the secure application, which is likely why you are seeing this behavior in your application.

[quote user="JyriLehtinen"]Where exactly should I be looking at, or even better, what would be the best method of finding such definitions?[/quote]

If you check the devicetree in Visual Studio code for your application, does UART1 have the okey status? This is a quick way to check whether the UART1 instance is enabled.

Best regards,
Karl

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Wed, 26 Oct 2022 12:04:11 GMT

Hi Karl,

I can't find any mention of "mcuboot-button0" in the compiled devicetree, any nrf9160-board or zephyr/dts/arm/nordic/ directories, neither does is show in the project devicetree view in VS Code (pin 14 shows it's unconfigured). I can't find any overlays for nrf9160-boards in mcuboot-directory either.

Only hit to P0.14 is the pinctrl-node in the uart1-sections, but uart1 is disabled:

   uart1: arduino_serial: uart@9000 {
                                compatible = "nordic,nrf-uarte";
                                reg = <0x9000 0x1000>;
                                interrupts = <9 NRF_DEFAULT_IRQ_PRIORITY>;
                                status = "disabled";
                                label = "UART_1";
                                current-speed = <115200>;
                                pinctrl-0 = <&uart1_default>;
                                pinctrl-1 = <&uart1_sleep>;
                                pinctrl-names = "default", "sleep";
                        };

      pinctrl: pin-controller {
                compatible = "nordic,nrf-pinctrl";
                uart0_default: uart0_default {
                        group1 {
                                psels = <NRF_PSEL(UART_TX, 0, 29)>,
                                        <NRF_PSEL(UART_RTS, 0, 27)>;
                        };

                        group2 {
                                psels = <NRF_PSEL(UART_RX, 0, 28)>,
                                        <NRF_PSEL(UART_CTS, 0, 26)>;
                                bias-pull-up;
                        };

                };

                uart0_sleep: uart0_sleep {
                        group1 {
                                psels = <NRF_PSEL(UART_TX, 0, 29)>,
                                        <NRF_PSEL(UART_RX, 0, 28)>,
                                        <NRF_PSEL(UART_RTS, 0, 27)>,
                                        <NRF_PSEL(UART_CTS, 0, 26)>;
                                low-power-enable;
                        };

                };

                uart1_default: uart1_default {
                        group1 {
                                psels = <NRF_PSEL(UART_TX, 0, 1)>,
                                        <NRF_PSEL(UART_RTS, 0, 14)>;
                        };

                        group2 {
                                psels = <NRF_PSEL(UART_RX, 0, 0)>,
                                        <NRF_PSEL(UART_CTS, 0, 15)>;
                                bias-pull-up;
                        };

                };

                uart1_sleep: uart1_sleep {
                        group1 {
                                psels = <NRF_PSEL(UART_TX, 0, 1)>,
                                        <NRF_PSEL(UART_RX, 0, 0)>,
                                        <NRF_PSEL(UART_RTS, 0, 14)>,
                                        <NRF_PSEL(UART_CTS, 0, 15)>;
                                low-power-enable;
                        };

                };

Where exactly should I be looking at, or even better, what would be the best method of finding such definitions?

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

Karl Ylvisaker — Wed, 26 Oct 2022 11:01:04 GMT

Hello Jyri,

I am glad to read that you were able to figure out the root cause of this issue. If I could ask, what button are you using for your mcuboot-button0 alias?
If the issue here is that the particular pin is used by mcuboot then it should indeed be visible in the devicetree - if you need this particular pin you could change the alias in the devicetree away from that particular pin as well.

Best regards,
Karl

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Tue, 25 Oct 2022 09:18:03 GMT

Ok, feels like it's at least partly solved for now. With the debugger I found that the PIN_CNF -registers were not identical for AIN0 - AIN5, and the P0.14 was configured as Output.

Setting the PIN_CNF -regs manually and the problem is gone...

static void set_pin_cnf(uint8_t pin) {
  NRF_P0_NS->PIN_CNF[pin] = 
      (GPIO_PIN_CNF_DIR_Input         << GPIO_PIN_CNF_DIR_Pos) 
    ||(GPIO_PIN_CNF_INPUT_Connect     << GPIO_PIN_CNF_INPUT_Pos)
    ||(GPIO_PIN_CNF_PULL_Disabled     << GPIO_PIN_CNF_PULL_Pos)
    ||(GPIO_PIN_CNF_DRIVE_S0S1        << GPIO_PIN_CNF_DRIVE_Pos)
    ||(GPIO_PIN_CNF_SENSE_Disabled    << GPIO_PIN_CNF_SENSE_Pos);
}

I still don't know why exactly this is the case, as no other part of the code touches GPIO, UART1 is disabled and there's nothing in the devicetree about P0.14.

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Mon, 24 Oct 2022 13:26:08 GMT

I did a bit of further testing and discovered that the problem is caused by CONFIG_BOOTLOADER_MCUBOOT=y. I need check what it exactly does that might e.g configure pull-up on the P0.14 pin.

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

JyriLehtinen — Thu, 20 Oct 2022 13:46:00 GMT

Hi,

The signal we're measuring is a floating AC-signal, so the +1,65 V is to average the signal at VDD/2..

On the test there there was nothing connected to X2.

I replicated the issue with the nRF9160-DK by using voltage divider to generate a voltage of VVD_GPIO/2, and connected both P and N -inputs to this VDD_GPIO/2.

Using the same code as the initial test

Scope still displays the step change with a width of roughly TACQ*2.

RE: SAADC - Scan mode connects inputs to VDD_GPIO?

ketiljo — Thu, 20 Oct 2022 13:16:59 GMT

Not sure if I understand the problem. You have 2x6 ohm resistors between the AIN inputs with a reference voltage in between? What do you have connected to X2?

Even with the opamp off, there's nothing here that can drive the lines up to VDD, unless you have a too high voltage on the X2 connector.

The configuration seems to be ok for max 0.6 V differential voltage. As long as the voltage isn't outside rails.