ADC calibration when using DualMode on a STM32H743

[d.zipperle.5512730769682947E12]

Post edited by ST moderator to be inline with the community rules for the code sharing. In next time please use </> button to paste your code and a linker script content. Please read this post: How to insert source code.

Hello,

I ran into a very strange problem with a STM32H743 that I don't understand.

I have the following config sequence:

1. MX_ADC1_Init() -> generated by CubeMX
2. MX_ADC2_Int() -> generated by CubeMX
3. HAL_ADCEx_Calibration_Start(&hadc1, ADC_CALIB_OFFSET_LINEARITY, ADC_SINGLE_ENDED)
4. HAL_ADCEx_Calibration_Start(&hadc2, ADC_CALIB_OFFSET_LINEARITY, ADC_SINGLE_ENDED)

The MX_ADC1_Init() contains the following generated code:

 multimode.Mode = ADC_DUALMODE_REGSIMULT;
 multimode.DualModeData = ADC_DUALMODEDATAFORMAT_DISABLED;
 multimode.TwoSamplingDelay = ADC_TWOSAMPLINGDELAY_1CYCLE;
 if (HAL_ADCEx_MultiModeConfigChannel(&hadc1, &multimode) != HAL_OK)
 {
   Error_Handler();
 }

This worked without a problem on all my boards so far and I was able to start a DMA conversion. However, I just got a new hardware batch (exactly the same PCB design as the previous ones) and here the HAL_ADCEx_Calibration_Start for the ADC2 (ADC1 works fine) always gets stuck for multiple seconds, until it timeouts and fails...

By playing around with the initialization sequence, I was able to find out that apparantely I have to call HAL_ADCEx_Calibration_Start for both ADCs before configuring the MultiMode.

Is wasn't able to find anything on this in the ApplicationNotes. Is there some explanation for my observation? What is the reason for the ADC2 calibration to get stuck, even though the ADC was not started before?

Is this a bug in the CubeMX generated code (that the MultiMode is configured too early)?

[lobna]

Dear @d.zipperle.5512730769682947E12 

The STM32H7 ADCs share some internal resources when operating in dual mode.
Calibration is a hardware process that adjusts internal offsets and linearity for each ADC. When Multi-Mode is configured, ADC1 and ADC2 become interdependent for conversion synchronization and data sharing.
Configuring Multi-Mode before calibration can cause ADC2 calibration to stall because ADC2 is effectively "linked" to ADC1 and cannot complete its standalone calibration properly.

The HAL driver function HAL_ADCEx_Calibration_Start() expects the ADC to be in a reset or independent state.
If Multi-Mode is already configured, ADC2 is no longer independent; it waits for triggers and synchronization from ADC1.
This causes the calibration routine on ADC2 to wait indefinitely (or eventually timeout) because the calibration sequence requires ADC2 to be free from multi-Mode synchronization constraints.

BR

Lobna

[d.zipperle.5512730769682947E12]

@lobna thank you for your detailed response!

This makes absolutely sense to me and means after changing the init sequence to perform the calibration before configuration of the MultiMode, the code should be correct.

However, I don't understand how I haven't run into this issue earlier. The previous sequence worked without problems on the same hardware. After doing more testing, I found that this issue only appears on ~25% of my boards (and is always resolved after changing the init sequence).

And also this means that the CubeMX generated initialization code is faulty, because when enabling the MultiMode config in CubeMX, the generated code will always apply the MultiMode config in MX_ADC1_Init() before any calibration was applied by the user code. 

[lobna]

Dear @d.zipperle.5512730769682947E12 

Regarding your first question: Variations in silicon quality, temperature, supply voltage, and PCB layout tolerances can influence the timing and behavior of ADC calibration. Moreover, differences in power-up sequences or electrical noise may affect the ADC’s internal state, which can increase the chances of calibration stalls.

As for CubeMX, the generated initialization code may not fully adhere to the recommended best practices for dual ADC calibration. I will escalate this internally for further evaluation.

BR

Lobna