ADC channels scrambled

RE: ADC channels scrambled

Bret Foreman — Wed, 25 Oct 2023 21:25:18 GMT

I found the problem here:

/ {
	zephyr,user {
		// compatible = "nordic,nrf-adc";
		io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>, <&adc 5>, <&adc 6>, <&adc 7>;
	};
};

I had left out channel 3 because I'm using that pin for the UART CTS signal. And that caused all subsequent channels above channel 2 to be incorrect. What is the correct way to make sure the CTS pin doesn't get mapped to an ADC channel?

RE: ADC channels scrambled

Bret Foreman — Wed, 25 Oct 2023 20:27:30 GMT

One piece of context that I should add is that my ADC setup comes from Nordic advice given in this thread: Zephyr adc init in device tree versus runtime

And here's where the device tree overlay example comes from: github.com/.../adc

Note that none of the device tree examples have a "compatible" line in the zephyr,user node, even though the SDK seems to flag a warning.

Note that some of the board files have the comment /* adjust channel number according to pinmux in board.dts */ in the zephyr,user node. But it's not clear which board.dts file is being used. In my case, I think I'm referencing the wrong one, but I don't know how to tell.

Here's another overlay example where they actually have the pin numbers shown as comments in the file. But in my build those defines don't get resolved to pin numbers at all: github.com/.../nrf52840dk_nrf52840.overlay

RE: ADC channels scrambled

Bret Foreman — Tue, 24 Oct 2023 23:05:57 GMT

I think I see the problem in my device tree overlay:

/ {
	zephyr,user {
		// compatible = "nordic,nrf-adc";
		io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 4>, <&adc 5>, <&adc 6>, <&adc 7>;
	};
};

There's a warning that zephyr,user node should have a "compatible" property. I tried adding that property (commented out in the code above) but got a device tree error in my build. What should be the proper device tree compatible line for this?

RE: ADC channels scrambled

Bret Foreman — Tue, 24 Oct 2023 22:53:46 GMT

I'm pretty sure this C-code is where the magic happens. But it's not clear where these macros are picking up the (incorrect) channel-to-pin mapping.

#define DT_SPEC_AND_COMMA(node_id, prop, idx) \
	ADC_DT_SPEC_GET_BY_IDX(node_id, idx),

/* Data of ADC io-channels specified in devicetree. */
static const struct adc_dt_spec adc_channels[] = {
	DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), io_channels,
			     DT_SPEC_AND_COMMA)
};

RE: ADC channels scrambled

Bret Foreman — Tue, 24 Oct 2023 20:05:56 GMT

By "scrambled" I mean that the voltage on a pin that's supposed to be associated with one channel reads back on another. Not all are wrong, though. For instance, AIN2 reads back the correct voltage. But the AIN5 "channel" reads the voltage on the AIN6 "pin" and AIN6 "channel" reads the voltage on the AIN7 "pin" and the AIN4 "channel" reads the voltage on the AIN6 "pin".

I suspect there is some incorrect bit shifting going on somewhere down in the driver. But it's pretty hard to figure out where that stuff happens.

RE: ADC channels scrambled

Karl Ylvisaker — Tue, 24 Oct 2023 09:56:22 GMT

Hello,

[quote user=""]when I use a voltage source to test them, the ADC channels are scrambled.[/quote]

Could you elaborate on what you mean when you say that the channels are scrambled?
For instance, do you see that when you set a voltage of X on the Y pin, the log shows a difference in the Z channel measurements, or something else?

In general, I highly recommend taking a look at these 2 example projects to see a demonstration of the two primary recommended ways to use the SAADC in the nRF Connect SDK, which is the approach similar to what you are doing now (CPU triggered sampling), and PPI based sampling.

Best regards,
Karl