STM32: NUCLEO_WL55JC internal (die) temperature incorrect

[0x657373656C6C]

Describe the bug I am facing an issue with stock Zephyr (latest main), unmodified, and reading internal die temperature from the ADC. I am using the sample provided in samples/sensor/stm32_temp_sensor and the following overlay:

&die_temp {
    compatible = "st,stm32-temp-cal";
    status = "okay";
    ts-cal1-addr = <0x1FFF75A8>;
    ts-cal2-addr = <0x1FFF75C8>;
    ts-cal1-temp = <30>;
    ts-cal2-temp = <130>;
    ts-cal-vrefanalog = <3300>;
    io-channels = <&adc1 12>;
};

&adc1 {
    status = "okay";
    has-temp-channel;
    has-vref-channel;
    has-vbat-channel;
    vref-mv = <3300>;
};

To the best of my knowledge (and many double-checks with the datasheet) I believe the register addresses and calibration temperatures to be correct.

On running the sample I get:

*** Booting Zephyr OS build zephyr-v3.1.0-4713-g4aa408484013  ***
STM32 Die temperature sensor test
Current temperature: -121.5 °C
Current temperature: -121.5 °C
Current temperature: -121.8 °C
Current temperature: -121.1 °C
Current temperature: -121.1 °C
Current temperature: -120.5 °C

To Reproduce Steps to reproduce the behavior:

1. Copy the dts things in to samples/sensor/stm32_temp_sensor/boards/nucleo_wl55jc.overlay
2. west build --pristine -b nucleo_wl55jc zephyr/samples/sensor/stm32_temp_sensor/
3. west flash
4. See error

Expected behavior Rational temperature readings somewhere in the room-temperature range.

Impact Just a bit of an inconvenience for LoRaWAN transmissions. As a side note, the battery reading is perfectly OK.

Logs and console output See description.

Environment (please complete the following information):

• OS: Linux
• Toolchain Zephry SDK 0.15.0
• Latest main

[FRASTM]

Also seen on : samples/sensor/stm32_temp_sensor/sample.sensor.stm32_temp_sensor, b_u585i_iot02a samples/sensor/stm32_temp_sensor/sample.sensor.stm32_temp_sensor, disco_l475_iot1 samples/sensor/stm32_temp_sensor/sample.sensor.stm32_temp_sensor, nucleo_l073rz samples/sensor/stm32_temp_sensor/sample.sensor.stm32_temp_sensor, nucleo_l152re samples/sensor/stm32_temp_sensor/sample.sensor.stm32_temp_sensor, stm32f3_disco

[0x657373656C6C]

I am not sure if this helps or is relevant but it seems clock related.

Here is an overlay for consideration:

&clk_hsi {
    status = "okay";
};

&pll {
    div-m = <1>;
    mul-n = <6>;
    div-p = <6>;
    div-r = <6>;
    div-q = <6>;
    clocks = <&clk_hsi>;
    status = "okay";
};

&rcc {
    clocks = <&pll>;
    clock-frequency = <DT_FREQ_M(16)>;
    cpu1-prescaler = <1>;
    cpu2-prescaler = <1>;
    ahb3-prescaler = <1>;
    apb1-prescaler = <4>;
    apb2-prescaler = <4>;
};

When I do this not only does the temperature readings indicate something in the 27-ish degrees but the battery also indicates a correct 3.33v in the case of my USB power so it seems that the ADC behaves better in this instance.

[FRASTM]

There is a sequence with the adc_stm32 driver that makes the ADC common register =0 at the moment the conversion is started. Testing the branch https://github.com/FRASTM/zephyr/tree/temp_sensor_wl still give a temperature below the expected one (around 9°C ) The converted data is always around 0x37c when expecting about 0x39a. Calibration values are correctly read at 0x3b' and 0x4cc.