Vrefint reads as 0 on some boards

[Meixner]

I have got 3 identical boards with STM32u5a5. For improving ADC accuracy I want to calibrate Vref using Vrefint. This is working fine on one board, but on the other two boards Vrefint reads as 0 using the same software. Other ADC channels seem to work on all boards.

Vrefint has been enabled and a delay has been added giving Vrefint time to settle.

On the working device I get ADC values around 24600 for Vrefint (left aligned), on the non-working devices exactly 0.

Since everything is working fine on one device, I wonder what could be the issue on the other two devices.

[Meixner]

I have found a difference: On the working devices code was compiled with optimizations turned off, on the failing devices, the code was compiled with optimizations turned on in gcc.

I have tracked down the failing code to the ADC calibration. The calibration code is essentially the same as in HAL_ADCEx_Calibration_Start(). Enabling gcc optimizations makes the code fail.

[Meixner]

Replacing

MODIFY_REG(hadc->Instance->CR, ADC_CR_CALINDEX, 0x9UL << ADC_CR_CALINDEX_Pos);
MODIFY_REG(hadc->Instance->CALFACT2, 0x00FF0000UL, 0x00020000UL);
SET_BIT(hadc->Instance->CALFACT, ADC_CALFACT_LATCH_COEF);

in HAL_ADCEx_Calibration_Start() by

MODIFY_REG(hadc->Instance->CR, ADC_CR_CALINDEX, 0x9UL << ADC_CR_CALINDEX_Pos);
__NOP();
__NOP();
MODIFY_REG(hadc->Instance->CALFACT2, 0x00FF0000UL, 0x00020000UL);
SET_BIT(hadc->Instance->CALFACT, ADC_CALFACT_LATCH_COEF);

fixed the issue.

[Amel NASRI · Accepted solution]

Hi @Meixner ,

In the current driver implementation, we have following sequence of code in HAL_ADCEx_Calibration_Start():

          /* Use a Data Memory Barrier instruction to avoid synchronization issues when accessing ADC registers */
          MODIFY_REG(hadc->Instance->CR, ADC_CR_CALINDEX, 0x9UL << ADC_CR_CALINDEX_Pos);
          __DMB();
          MODIFY_REG(hadc->Instance->CALFACT2, 0xFFFFFF00UL, 0x03021100UL);
          __DMB();
          SET_BIT(hadc->Instance->CALFACT, ADC_CALFACT_LATCH_COEF);

Are you using an older version than 1.6.0for STM32CubeU5 firmware package?

-Amel

[waclawek.jan]

Hi @Amel NASRI ,

I can't see description of the delays needed in Software procedure to reinject the calibration factor into the ADC section in RM0456 Rev 5. Am I overlooking something?

On a broader note, this is probably due to given registers being in the asynchronous clock domain, thus the procedure needed is dependent on the particular ADC clock selected, am I correct? Thus delays like this appears to be a common theme across several newer STM32 families' ADCs, and the complaints on "not working" are increasingly common here in the forum. Of course, users who don't "see" the innards can cope with these only symptomatically, without deeper understanding of the role of particular settings of the clocks; and it appears that ST just throws in delays haphazardly to Cube to cover up the problem, again, without deeper explanation.

So, what about returning to the drawing desk and documenting in enough depth the two ADC clock domains, the exact procedure needed to transfer data from one to the other, and list, which register is in which domain? That surely will improve the ADC handling A LOT. And I mean, for *all* STM32 faimilies.

Well, unless ST is stubbornly determined just to hide things under the carpet in Cube's entanglements.

JW

@KB-IDEA 

[Meixner]

Where would I find 1.6.0?

https://www.st.com/en/embedded-software/x-cube-freertos.html lists 1.2.0 as latest release.

[Amel NASRI]

Hi @waclawek.jan ,

As usual, your feedback is valuable and it requires a deep analysis and involvement of our experts to provide a complete response and take some possible actions. Be patient, I'll come back.

Thus delays like this appears to be a common theme across several newer STM32 families' ADCs, and the complaints on "not working" are increasingly common here in the forum.

---

I'm aware of one case: STM32U5 extended calibration procedure in RM0456 Rev 5 page 1269 is buggy where documentation update is taken as action.

Are there other cases that I may have missed?

-Amel

[waclawek.jan]

Hi @Amel NASRI ,

e.g.

https://community.st.com/t5/stm32-mcus-products/adc-calibration-doesn-t-complete-on-stm32g0c1re/td-p/590459

https://community.st.com/t5/stm32-mcus-products/adc-register-adrdy-never-sets-when-i-enable-the-adc-so-it-keeps/m-p/106159/highlight/true#M17007

Maybe they are moot: I don't have the time/resources/abilities, nor access to the internal design, to judge and bring definitive conclusions about them.

Maybe there are more which went below my radar. I tend to ignore ADC-related threads, as I usually can't help, because ADC is very complicated (in a usually underappreciated way) and the details differ significantly between the individual families (ADC is perhaps the most varying module of them all).

JW

[Amel NASRI]

Hi @Meixner,

You can download latest STM32CubeU5 package version from st.com https://www.st.com/en/embedded-software/stm32cubeu5.html or Github repository https://github.com/STMicroelectronics/STM32CubeU5.

-Amel