STM32 ADC readings almost constant regardless of input voltage (Zephyr adc_dt sample)

[DaviVolcan]

Hi everyone,

I'm currently starting with Zephyr and running into issues with ADC readings that I can't explain.

Setup
Board: STM32 Nucleo-F446RE
Build command:
west build -p -b nucleo_f446re
Sample used: adc_dt (no changes in prj.conf, it's the original from the sample)
Devicetree overlay

Here is the overlay I'm using:

/ {
	zephyr,user {
		/* Nucleo-F446RE Arduino A0 = PA0 = ADC1_IN0 */
		io-channels = <&adc1 0>;
	};
};

&adc1 {
	status = "okay";
	#address-cells = <1>;
	#size-cells = <0>;
	pinctrl-names = "default";
	st,adc-prescaler = <4>;
	pinctrl-0 = <&adc1_in0_pa0>;

	channel@0 {
		reg = <0>;
		zephyr,gain = "ADC_GAIN_1";
		zephyr,reference = "ADC_REF_INTERNAL";
		zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
		zephyr,resolution = <12>;
	};
};

Problem description

No matter what voltage I apply to PA0 (ADC1_IN0), the readings barely change.

I tested three conditions:

PA0 connected to GND
PA0 connected to 3.3V
PA0 left floating
Results:

1. PA0 connected to GND:

ADC reading[14]:
- adc@40012000, channel 0: 134217729 = 108134400 mV
ADC reading[15]:
- adc@40012000, channel 0: 134217731 = 108134402 mV
ADC reading[16]:
- adc@40012000, channel 0: 134217732 = 108134403 mV
ADC reading[17]:
- adc@40012000, channel 0: 134217728 = 108134400 mV
ADC reading[18]:
- adc@40012000, channel 0: 134217728 = 108134400 mV

2. PA0 connected to 3.3V:

ADC reading[92]:
- adc@40012000, channel 0: 134221810 = 108137688 mV
ADC reading[93]:
- adc@40012000, channel 0: 134221816 = 108137693 mV
ADC reading[94]:
- adc@40012000, channel 0: 134221816 = 108137693 mV
ADC reading[95]:
- adc@40012000, channel 0: 134221818 = 108137695 mV
ADC reading[96]:
- adc@40012000, channel 0: 134221820 = 108137696 mV

3. PA0 floating:

ADC reading[166]:
- adc@40012000, channel 0: 134218711 = 108135191 mV
ADC reading[167]:
- adc@40012000, channel 0: 134218703 = 108135185 mV
ADC reading[168]:
- adc@40012000, channel 0: 134218703 = 108135185 mV
ADC reading[169]:
- adc@40012000, channel 0: 134218688 = 108135173 mV
ADC reading[170]:
- adc@40012000, channel 0: 134218698 = 108135181 mV

Observation

There is a difference between the three cases, but it's extremely small:

GND ≈ 108134400 mV
Floating ≈ 108135180 mV
3.3V ≈ 108137690 mV

So the variation is only ~3,000 mV in the reported value, which clearly does not reflect the actual input range (0V → 3.3V).

Also, the absolute values themselves seem completely off (very large raw values and unrealistic millivolt conversion).

Additional notes
I observed the same behavior on another STM32 board before switching to the Nucleo-F446RE
The issue seems very similar to what is described in this discussion:
#76493
Questions
Am I missing something in the ADC configuration (reference, gain, calibration, etc.)?
Could this be related to how adc_dt interprets or converts the raw values?
Is there any known issue with ADC on STM32 + Zephyr in this context?

Any help or pointers would be greatly appreciated.

Thanks!

[DaviVolcan]

I found the cause and wanted to share in case it helps others.
In samples/drivers/adc/adc_dt/src/main.c, changing:

uint32_t buf;

to

uint16_t buf;

made my measurements look correct on nucleo_f446re .
Overlay:

/ {
	zephyr,user {
		/* Nucleo-F446RE Arduino A0 = PA0 = ADC1_IN0 */
		io-channels = <&adc1 0>;
	};
};

&adc1 {
	status = "okay";
	#address-cells = <1>;
	#size-cells = <0>;
	pinctrl-names = "default";
	st,adc-prescaler = <4>;
	pinctrl-0 = <&adc1_in0_pa0>;

	channel@0 {
		reg = <0>;
		zephyr,gain = "ADC_GAIN_1";
		zephyr,reference = "ADC_REF_INTERNAL";
		zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
		zephyr,resolution = <12>;
	};
};

Why this happens (my current understanding)

For this setup, the ADC sample appears to be 16-bit wide, but the sample stores it in a 32-bit variable (buf) and then uses that value directly for single-ended channels.
So only the lower 16 bits are valid ADC data, while the upper bits may contain stale/undefined data. That can produce very large raw values (e.g. 1342177xx) and unrealistic mV conversions.

Current status

Using uint16_t buf gives expected behavior (clear and realistic difference between GND / floating / 3.3V), but this may only be a workaround in the sample path and not the full root cause.
I will try to investigate this more, because I may have made it work without fully solving the underlying issue.

Suggestion

It may help to make the sample safer by default (16-bit buffer, or masking/sign-extension based on resolution) to avoid confusion on targets where drivers write 16-bit samples.

[adtvtk]

Hello,
Noticed Clock source is not getting set. Can you try with
st,adc-clock-source = "SYNC";
Below dts config worked for me.

&adc3 {
pinctrl-0 = < &adc3_inp10_pc0 >;
pinctrl-names = "default";
st,adc-clock-source = "SYNC";
status = "okay";
st,adc-prescaler = <4>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0>;
#io-channel-cells = <1>;
zephyr,gain = "ADC_GAIN_1";
zephyr,reference = "ADC_REF_INTERNAL";
zephyr,acquisition-time = <ADC_ACQ_TIME_MAX>;
zephyr,oversampling = <8>;
zephyr,resolution = <12>;
};

[gautierg-st]

@DaviVolcan,
I'm glad you were able to solve your issue. Indeed the ADC_DR register size on F446 is 16 bits. When looking at the values you got with the 32-bit buffer, we can see that they have an incorrect bit set but are otherwise correct (ie 0V gives 0x800 0001, 3.3V gives 0x800 0FFA). If you apply a 12-bit mask on them, you get the correct value.
I'm not sure where this intempestive bit comes from. Maybe from the fact that the buf variable is not initialized to 0, and is already "polluted" from the start. The driver then only writes the lower 16-bit, leaving the higher 16-bit untouched. Could you try to explicitly set it to 0?

@adtvtk,
FYI, for the STM32F4x series, st,adc-clock-source cannot be anything other than SYNC, so it is set directly in the dtsi file, and it is not necessary to repeat it in the board dts or in an overlay.

[basilegrunersmile]

Hello,
This behavior was introduced by #104693. I faced the same issue recently with another board (nucleo u545).
The adc_sequence sample select the right buffer size using a specific Kconfig (Not documented in README.rst BTW) :

#ifdef CONFIG_SEQUENCE_32BITS_REGISTERS
uint32_t channel_reading[CONFIG_SEQUENCE_SAMPLES][CHANNEL_COUNT];
#else
uint16_t channel_reading[CONFIG_SEQUENCE_SAMPLES][CHANNEL_COUNT];
#endif

Maybe we should do the same for adc_dt ?

[DaviVolcan]

Hello,

Nice catch, thanks for pointing that out!

I’m still new to Zephyr, so I just assumed I was doing something wrong and started debugging my own setup.

Do you think we should report this as a bug? Ideally, it would be good to fix it and open a pull request.

[basilegrunersmile]

Sure ! Don't hesitate to open an issue.

[DaviVolcan]

Hi everyone,

I’ve made some progress on this issue and wanted to share additional findings.

At the moment, I already have a workaround working on the NUCLEO-F446RE. However, when testing on a different (Chinese) board using an STM32H743IIT6, I’m seeing a very similar problem — it looks like the ADC is not capturing the correct input range.

Observed behavior

• When I adjust the potentiometer down to 0V, I get:

adc@40022000, channel 16: 0x00008000

• As soon as the input reaches around ~24 mV, the value jumps to:

adc@40022000, channel 16: 0x0000ff

This makes it seem like the ADC is saturating or not using the expected resolution range.

Prescaler investigation

After reading issue #76493 and learning about the ADC prescaler, I tried increasing it (current value is 4), expecting it might help.

However, every time I attempt to change the prescaler to a higher value, the build fails. I suspect there may be some limitation in the ADC driver, but I haven’t investigated that deeply yet. From what I saw in STM32CubeMX, the prescaler should be configurable up to 128.

Clock configuration doubts

To better understand the clock setup, I checked STM32CubeMX to visualize the clock tree, since I suspect this might be a clock misconfiguration on my side.

While reading this application note:
https://www.st.com/resource/en/application_note/an5354-getting-started-with-the-stm32h7-series-mcu-16bit-adc-stmicroelectronics.pdf

I noticed in Table 12 that for the STM32H743IIT6 (LQFP-176 with 3 ADCs), the maximum ADC clock for 16-bit resolution is 7 MHz (though I’m not completely sure I interpreted that correctly — I’ll revisit the document).

Open questions

How can I ensure the ADC is using PLL3 as its clock source in Zephyr?
Is there any known limitation in the ADC driver regarding prescaler values?
Could this behavior be caused by an incorrect ADC clock configuration?

Hardware details

External crystal: 25 MHz
Board voltage: 3.3V
Device tree is still a work in progress (especially memory configuration)

Device tree (WIP)

stm32h743_coreboard.dts:

/*
 * Copyright (c) 2026 Davi Alexandre Volcan <davi.volcan2@gmail.com>
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/dts-v1/;
#include <st/h7/stm32h743Xi.dtsi>
#include <st/h7/stm32h743xihx-pinctrl.dtsi>
#include <zephyr/dt-bindings/input/input-event-codes.h>

/ {
	model = "STM32H743IIT6 Core Board";
	compatible = "st,stm32h743_coreboard";

	chosen {
		zephyr,console = &usart1;
		zephyr,shell-uart = &usart1;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
	};

	leds {
		compatible = "gpio-leds";

		user_led0: led_0 {
			gpios = <&gpiob 0 GPIO_ACTIVE_LOW>;
			label = "Red led";
		};

		user_led1: led_1 {
			gpios = <&gpiob 1 GPIO_ACTIVE_LOW>;
			label = "Green led";
		};

	};

	gpio_keys {
		compatible = "gpio-keys";

		user_button0: key0 {
			label = "key0";
			gpios = <&gpioa 1 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
			zephyr,code = <INPUT_KEY_0>;
		};

		//		user_button1: wk_up {
		//			label = "wk_up";
		//			gpios = <&gpioa 0 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
		//			zephyr,code = <INPUT_KEY_0>;
		//		};

	};

	aliases {
		led0 = &user_led0;
		led1 = &user_led1;
		sw0 = &user_button0;
		eeprom-0 = &eeprom;
	};


	sdram1: sdram@c0000000 {
		compatible = "zephyr,memory-region";
		//		device_type = "memory";
		reg = <0xc0000000 DT_SIZE_M(32)>;
		zephyr,memory-region = "SDRAM1";
		zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>;

	};

};

&i2c2 {
	status = "okay";
	pinctrl-0 = <&i2c2_scl_ph4 &i2c2_sda_ph5>;
	pinctrl-names = "default";

	eeprom: eeprom@50 {
		compatible = "atmel,at24";
		reg = <0x50>;
		size = <DT_SIZE_K(2)>;
		pagesize = <8>;
		address-width = <8>;
		timeout = <5>;
	};

};

&usart1 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&usart1_tx_pa9 &usart1_rx_pa10>;
	pinctrl-names = "default";


};

&quadspi {
	pinctrl-0 = <&quadspi_clk_pb2 &quadspi_bk1_ncs_pb6
	             &quadspi_bk1_io0_pf8 &quadspi_bk1_io1_pf9
	             &quadspi_bk1_io2_pf7 &quadspi_bk1_io3_pf6>;
	pinctrl-names = "default";
	status = "okay";

	w25q128jvsiq: qspi-nor-flash@0 {
		compatible = "st,stm32-qspi-nor";
		reg = <0>;
		size = <DT_SIZE_M(128)>;
		qspi-max-frequency = <133000000>;
		cs-high-time = <7>;
		status = "okay";
	};
};

&fmc {
	pinctrl-0 = <&fmc_nbl0_pe0 &fmc_nbl1_pe1
	             &fmc_sdclk_pg8 &fmc_sdnwe_pc0 &fmc_sdcke0_ph2
	             &fmc_sdne0_ph3 &fmc_sdnras_pf11 &fmc_sdncas_pg15
	             &fmc_a0_pf0 &fmc_a1_pf1 &fmc_a2_pf2 &fmc_a3_pf3 &fmc_a4_pf4
	             &fmc_a5_pf5 &fmc_a6_pf12 &fmc_a7_pf13 &fmc_a8_pf14
	             &fmc_a9_pf15 &fmc_a10_pg0 &fmc_a11_pg1 &fmc_a12_pg2
	             &fmc_a14_pg4 &fmc_a15_pg5 &fmc_d0_pd14 &fmc_d1_pd15
	             &fmc_d2_pd0 &fmc_d3_pd1 &fmc_d4_pe7 &fmc_d5_pe8 &fmc_d6_pe9
	             &fmc_d7_pe10 &fmc_d8_pe11 &fmc_d9_pe12 &fmc_d10_pe13
	             &fmc_d11_pe14 &fmc_d12_pe15 &fmc_d13_pd8 &fmc_d14_pd9
	             &fmc_d15_pd10>;
	pinctrl-names = "default";
	status = "okay";

	sdram {
		status = "okay";
		power-up-delay = <200>;
		num-auto-refresh = <8>;
		mode-register = <0x220>;
		/*
		 * Auto refresh command shall be issued every 15.625 us
		 * and is calculated as ((15.625 * SDRAM_CLK_MHZ) - 20)
		 * Note: SDRAM_CLK_MHZ = HCLK_MHZ / 2 (108 MHz)
		 */
		refresh-rate = <2078>;

		bank@0 {
			reg = <0>;
			st,sdram-control = <STM32_FMC_SDRAM_NC_9
			                    STM32_FMC_SDRAM_NR_13
			                    STM32_FMC_SDRAM_MWID_16
			                    STM32_FMC_SDRAM_NB_4
			                    STM32_FMC_SDRAM_CAS_2
			                    STM32_FMC_SDRAM_SDCLK_PERIOD_2
			                    STM32_FMC_SDRAM_RBURST_ENABLE
			                    STM32_FMC_SDRAM_RPIPE_0>;
			st,sdram-timing = <2 10 6 8 2 2 2>;
		};
	};
};

&clk_hse {
	clock-frequency = <DT_FREQ_M(25)>;
	status = "okay";
};

&pll {
	div-m = <5>;
	mul-n = <192>;
	div-p = <2>;
	div-q = <4>;
	div-r = <4>;
	clocks = <&clk_hse>;
	status = "okay";
};

&pll3 {
	div-m = <2>;
	mul-n = <12>;
	div-p = <2>;
	div-q = <2>;
	div-r = <5>;
	clocks = <&clk_hse>;
	status = "okay";
};

&rcc {
	clocks = <&pll>;
	clock-frequency = <DT_FREQ_M(480)>;
	d1cpre = <1>;
	hpre = <2>;
	d1ppre = <2>;
	d2ppre1 = <2>;
	d2ppre2 = <2>;
	d3ppre = <2>;
};

&pwr {
	power-supply = "ldo";
};

stm32h743_coreboard.overlay:

/ {
    zephyr,user {
        io-channels = <&adc1 16>;
    };

};

&perck {
	clocks = <&rcc STM32_SRC_HSE CKPER_SEL(2)>;
	status = "okay";
};

&adc1 {
//    clocks = <&rcc STM32_CLOCK(AHB1, 5)>,
//             <&rcc STM32_SRC_PLL3_R ADC_SEL(2)>;
//    clock-names = "adcx", "adc_ker";
//	st,adc-clock-source = "ASYNC";
    status = "okay";
    pinctrl-0 = <&adc1_inp16_pa0>;
    pinctrl-names = "default";
    st,adc-clock-source = "SYNC";
    st,adc-prescaler = <4>;
//    vref-mv = <3300>;

    #address-cells = <1>;
    #size-cells = <0>;

    channel@10 {
        /* Explicitly single-ended: no zephyr,differential property */
        reg = <16>;
        zephyr,gain = "ADC_GAIN_1";
        zephyr,reference = "ADC_REF_INTERNAL";
        zephyr,acquisition-time = <ADC_ACQ_TIME_MAX>;
        zephyr,resolution = <16>;
    };
};

@gautierg-st — since you seem quite familiar with this area, any insights would be greatly appreciated.

(UPDATE: I totally misunderstood table 12)

[gautierg-st]

Using the SYNC clock source, this means that your ADC is clocked by HCLK with some additional prescalers, in your case 2 (from RCC) then 4 (from ADC). With a HCLK of 480 MHz, that makes a source clock of 60 MHz which seems a bit too high from what can be found in the datasheet (max is 50 MHz). That may explain the erratic values that you see.

In synchronous mode, you cannot use a higher ADC prescaler, and modifying the HCLK prescaler will impact your whole system.

Your other solution is to use an asynchronous clock (ASYNC). For that you need to define a specific source clock.

If you want to use the PLL3_R, then your clock properties should look like this:

clocks = <&rcc STM32_CLOCK(AHB1, 5)>,
         <&rcc STM32_SRC_PLL3_R ADC_SEL(1)>;

If you want to use PER_CK, then it should be

clocks = <&rcc STM32_CLOCK(AHB1, 5)>,
         <&rcc STM32_SRC_CKPER ADC_SEL(2)>;

Using an asynchronous clock allows setting an ADC prescaler value up to 256.

[DaviVolcan]

Hi everyone,

I finally figured out why it wasn’t working on the H7.

An incorrect measurement initially led me down the wrong path — I thought I was measuring VREF at 3.3V, but I was actually measuring ANALOG_VDD, which is correctly at 3.3V. Both VREF and ANALOG_VDD share very similar circuitry, but ANALOG_VDD is connected to the 3.3V regulator, while VREF is routed to a header pin on the board.

It turned out that VREF was actually disconnected and floating. Once I properly connected that pin to 3.3V, the measurements matched the expected values.

A pretty stupid mistake, but it cost me quite some time to track down. I plan to document this properly when I upstream the board support.

I'm currently waiting for the official documentation/schematics from the Chinese manufacturer, but communication with them has been a bit difficult, which slowed things down.

I will still test the ADC clock configuration more thoroughly, but for now it seems to be working. Thanks, @gautierg-st !

Thanks a lot to everyone who helped!

Regarding the issue pointed out by @basilegrunersmile , I’m not sure I’ll be able to look into it right away since I have exams this week at university. I’d also like to better understand Zephyr’s contribution guidelines before working on it.