STM32H563 / STM32Cube FW_H5 v1.6.0 regression: `ADC2_INP0` broken by `LL_ADC_EnableChannel0_GPIO()` change, reference manual unclear
I found an ADC regression on `STM32H563RG` after upgrading from `STM32Cube FW_H5 v1.5.1` to `v1.6.0`.
Setup:
- MCU: `STM32H563RG`
- Old package: `STM32Cube FW_H5 v1.5.1`
- New package: `STM32Cube FW_H5 v1.6.0`
- CubeMX: `6.17.0`
Symptom:
- I sample multiple external channels on `ADC2`, including `ADC2_INP0`.
- Before the upgrade, `ADC2_INP0` measured correctly.
- After the upgrade, `ADC2_INP0` no longer reflects the actual GPIO input voltage, while the other ADC2 channels still behave correctly.
This is not a sampling-time or rank-order issue. The problem follows `ADC2_INP0` specifically.
The regression appears to come from a change in the LL helper for Channel 0 GPIO switch control.
In older FW_H5 code, `LL_ADC_EnableChannel0_GPIO()` always set `ADC1->OR.OP0`, regardless of the ADC instance passed in.
In FW_H5 v1.6.0, that helper was changed to set `ADCx->OR.OP0` instead. On STM32H563, that breaks `ADC2_INP0`.
What fixes the problem in my testing is:
- still enabling Channel 0 GPIO switch control when `ADC2_INP0` is configured
- but using `ADC1->OR.OP0`, not `ADC2->OR.OP0`
So for STM32H563, `ADC2_INP0` appears to depend on the shared GPIO switch control bit in `ADC1->OR.OP0`.
The reference manual is also misleading here. The description of `ADCx->OR.OP0` says:
Bit 0 OP0: Option bit 0
For ADC1:
0: INP0/INN1 GPIO switch control disabled
1: INP0/INN1 GPIO switch control enabled
Note: This option bit must be set to 1 when ADCx_INP0 or ADCx_INN1 channel is selected.
For ADC2:
0: VDDCORE channel disabled
1: VDDCORE channel enabledThis wording makes it sound like:
- `OP0` enables external `INP0/INN1` routing only for `ADC1`
- `ADC2.OP0` is only related to `VDDCORE`
- `ADC2_INP0` does not rely on any such switch bit
But actual behavior appears different: `ADC2_INP0` is a valid external channel, and it only works correctly when the Channel 0 GPIO switch is enabled through `ADC1->OR.OP0`.
Requested fixes:
- Please fix the HAL/LL implementation so `ADC2_INP0` uses the correct switch-control behavior.
- Please update the reference manual wording for `ADCx->OR.OP0` to explicitly describe how `ADC2_INP0` is routed.
- If `ADC2_INP0` depends on `ADC1->OR.OP0`, please state that directly in the reference manual and LL/HAL comments.
As written now, both the software comments and the reference manual suggest that `ADC2` is unrelated to this switch bit, which makes this regression very difficult to diagnose.