Solved
STM32H5xxLL_ADC.H bug in STM32Cube FW_H5 V1.6.0
Post edited by ST moderator to be compliant with the ST community rules especially for sharing a code.
The latest Cube H5 package (STM32Cube FW_H5 V1.6.0) has broken the use of ADC2_INP0 with the following changes to LL_ADC_EnableChannel0_GPIO and LL_ADC_DisableChannel0_GPIO in STM32H5xxLL_ADC.H.
Previous,
__STATIC_INLINE void LL_ADC_EnableChannel0_GPIO(const ADC_TypeDef *ADCx)
{
/* Prevent unused argument(s) compilation warning */
(void)(ADCx);
SET_BIT(ADC1->OR, ADC_OR_OP0);
}Current,
__STATIC_INLINE void LL_ADC_EnableChannel0_GPIO(ADC_TypeDef *ADCx)
{
SET_BIT(ADCx->OR, ADC_OR_OP0);
}Previous,
__STATIC_INLINE void LL_ADC_DisableChannel0_GPIO(const ADC_TypeDef *ADCx)
{
/* Prevent unused argument(s) compilation warning */
(void)(ADCx);
CLEAR_BIT(ADC1->OR, ADC_OR_OP0);
}Current,
__STATIC_INLINE void LL_ADC_DisableChannel0_GPIO(ADC_TypeDef *ADCx)
{
CLEAR_BIT(ADCx->OR, ADC_OR_OP0);
}According to the reference manual the OP0 bit is applicable to ADC1 only for control of INP0/INN1, which is consistent with the old code. However HAL_ADC_ConfigChannel() does not check that the ADC instance is ADC1 before calling LL_ADC_EnableChannel0_GPIO on CHANNEL_0, which means ADC2->OR bit OP0 is set, which is actually "VDDCORE channel" enable.
In current state reads of ADC2 channel 0 ADC give unexpected results; I guess ADC2-CH0 is now reading VDDCORE instead.