Incorrect temperature and core voltage reading if analog power supply (Vdda) is different from 3.3V

[amalashanka]

The problems comes from using a hard-coded macro VDDA_APPLI that is fixed to 3300mV in ADCCTRL module:

STM32CubeWBA/Projects/Common/WPAN/Modules/adc_ctrl.c

Line 71 in 1e4d35e

#define VDDA_APPLI (3300UL)

As a result, if a different MCU supply voltage is used (e.g., 3V), the ADCCTRL will silently produce incorrect readings, still assuming the Vdda is 3300mV.

Steps to reproduce:

1. Use NUCLEO-WBA55 or NUCLEO-WBA65 board
2. Use any CubeMX example that includes ADCCTRL module and modify it to periodically print out core temperature or core voltage
3. Ensure it produces plausible results (e.g., temperature around 30 degrees Celsius, core voltage around 3300mV)
4. Use STLINK-V3PWR or similar to feed Vdd line with 3V instead of 3.3V using JP2 header on the Nucleo board
5. Observe incorrect readings

The suggestion is to move the definition of VDDA_APPLI from adc_ctrl.c into application configuration header (app_conf.h) as this is clearly an application-specific parameter.

Going a bit further with improvements, it would be nice to treat VDDA_APPLI as a function-like macro. With this the users who want or need to use the actual reference voltage reading will be able to define VDDA_APPLI in their app_conf.h to call their function to provide the reference voltage readings, while those who are ok with a hard-coded value are still ok to use it. For example:

#define CFG_GET_VDDA_APPLI()         my_get_reference_voltage_func()
vs
#define CFG_GET_VDDA_APPLI()         (3300U)

Identified instances of the issue:

• STM32CubeWBA/Projects/Common/WPAN/Modules/adc_ctrl.c

  Line 71 in 1e4d35e

  #define VDDA_APPLI (3300UL)

• STM32CubeWBA/Projects/Common/WPAN/Modules/adc_ctrl.c

  Line 375 in 1e4d35e

  VDDA_APPLI,

• STM32CubeWBA/Projects/Common/WPAN/Modules/adc_ctrl.c

  Line 382 in 1e4d35e

  *p_ReadValue = __LL_ADC_CALC_TEMPERATURE (VDDA_APPLI,

• STM32CubeWBA/Projects/Common/WPAN/Modules/adc_ctrl.c

  Line 455 in 1e4d35e

  *p_ReadValue = __LL_ADC_CALC_DATA_TO_VOLTAGE (VDDA_APPLI,

[RJMSTM]

Hello @amalashanka,

I tried to reproduce the problem, but in reality, this module is not used in any example within our firmware. The macro
#define VDDA_APPLI (3300UL)
is always included in the main.c file of all ADC examples, and the measurements in these examples are correct.
I do not fully understand where exactly your problem occurs. It might be in your own application, but in our firmware, I only found the file adc_ctrl.c, which is not used in any project.

Regards,
Rania

[amalashanka]

Hi @RJMSTM,

The ADCCTRL module (adc_ctrl.c) is specific to the BLE projects, it's not included in the examples for ADC peripheral. This module is used to manage concurrent access to ADC between the Link Layer of the STM32_WPAN middleware and the user application. You can use any BLE-enabled sample project as a starting point, e.g., Projects/NUCLEO-WBA55CG/Applications/BLE/BLE_HeartRateFreeRTOS

The usage of ADCCTRL by the Link Layer is located, for example, here:

STM32CubeWBA/Projects/NUCLEO-WBA55CG/Applications/BLE/BLE_HeartRateFreeRTOS/STM32_WPAN/Target/ll_sys_if.c

Line 247 in 1e4d35e

TEMPMEAS_RequestTemperatureMeasurement();

This triggers the temperature measurement module which consequently triggers the ADCCTRL module:

STM32CubeWBA/Projects/Common/WPAN/Modules/temp_measurement.c

Lines 79 to 80 in 1e4d35e

	ADCCTRL_RequestTemperature (&LLTempRequest_Handle,
	&temperature_value);

Unfortunately, there's no readily available BLE example that calls ADCCTRL from the user app as well, but it's easy to extend the aforementioned BLE_HeartRateFreeRTOS with a periodic call to ADCCTRL_RequestTemperature() from a user-defined task parallel to the Link Layer activities.