STM32CubeH7
STM32CubeH7 copied to clipboard
ADC3 Oversampling Ratio incorrectly set
The Bug
In the function LL_ADC_ConfigOverSamplingRatioShift
(and corresponding LL_ADC_GetOverSamplingRatio
) the CFGR2->OVSR
does not handle all cases correctly.
More detail
For example, for STM32H723's the CFGR2->OVSR
field is different for ADC1+2 and ADC3.
For ADC1 and ADC2:
Bits 25:16 OSVR[9:0]: Oversampling ratio This bitfield is set and cleared by software to define the oversampling ratio. 0: 1x (no oversampling) 1: 2x 2: 3x ... 1023: 1024x
For ADC3:
Bits 4:2 OVSR[2:0]: Oversampling ratio This bitfield is set and cleared by software to define the oversampling ratio. 000: 2x 001: 4x 010: 8x 011: 16x 100: 32x 101: 64x 110: 128x 111: 256x
Currently the LL dirver does not handle this special case.
Proposed Solution Follow how the other functions handled this special case. For example:
__STATIC_INLINE void LL_ADC_ConfigOverSamplingRatioShift(ADC_TypeDef *ADCx, uint32_t Ratio, uint32_t Shift)
{
MODIFY_REG(ADCx->CFGR2, ADC_CFGR2_OVSS, Shift);
#if defined(ADC_VER_V5_V90)
if (ADCx == ADC3) {
MODIFY_REG(adc->CFGR2, ADC3_CFGR2_OVSR, (Ratio - 1UL) << ADC3_CFGR2_OVSR_Pos);
} else {
#endif
MODIFY_REG(adc->CFGR2, ADC_CFGR2_OVSR, (Ratio - 1UL) << ADC_CFGR2_OVSR_Pos);
if defined(ADC_VER_V5_V90)
}
#endif
}
Edit: It seems all H7 devices has the ratio set from 0->1023 for ADC1 and 2.
Could this issue be a duplicate of the https://github.com/STMicroelectronics/STM32CubeH7/issues/170?
Could this issue be a duplicate of the #170?
@FRASTM definitely not, since I raised both these issues myself. They are probably related, but not duplicates. They point to different functions:
#170: LL_ADC_SetResolution(adc, LL_ADC_RESOLUTION_12B);
#177: LL_ADC_ConfigOverSamplingRatioShift(...)
Hi @heinwessels,
Thank you for this contribution. An internal tracker has been logged and a fix will be implemented and made available in the frame of a future release.
Thank you once more for your contribution.
With regards
ST Internal Reference: 116019