cancel
Showing results for 
Search instead for 
Did you mean: 

What can cause an ADC calibration fails?

JLojo
Associate III

We are starting (difficultly due to the lack of devices) the pre-production of our system built around an STM32 H743VIT, and, on already two systems (out of about 50), we have failures initializing ADC 2. For the first one, replacing the MCU was successful, but before replacing all (rare) MCUs, I'm wondering if there can not be any other possibility to fix it.

The code for ADC initialization is quite basic:

if (HAL_ADCEx_Calibration_Start(&hadc1,ADC_CALIB_OFFSET_LINEARITY,ADC_SINGLE_ENDED)!=HAL_OK) PRINT(console_ctx,"Error ADC1 Calibration\n");
  if (HAL_ADCEx_Calibration_Start(&hadc2,ADC_CALIB_OFFSET_LINEARITY,ADC_SINGLE_ENDED)!=HAL_OK) PRINT(console_ctx,"Error ADC2 Calibration\n");
  if (HAL_ADCEx_Calibration_Start(&hadc3,ADC_CALIB_OFFSET_LINEARITY,ADC_SINGLE_ENDED)!=HAL_OK) PRINT(console_ctx,"Error ADC3 Calibration\n");

And each time the failure occurs on ADC2 (ADC1 and ADC3 works perfectly!)

Is it possible we got a bad batch of MCUs (there were so difficult to find!)?

I tried adding delays between calibration, but no changes.

Any idea/advice?

thanks

JYL

12 REPLIES 12

What about to debug step by step and take a look why HAL_ADCEx_Calibration_Start return error ? Or take a look into hadc->State to check error details. From function source code there are two ways.

a) ADC is enabled when starting calibration

b) timeout elapsed before ADCAL set

At least it will help indetify root of problem.

JLojo
Associate III

Sorry for the missing information: of course project has been run in debug mode and this is definitely a timeout condition (which appears quite obviously since the MCU stay stuck for about 1 minute).

What is surprising is why systematically on ADC2?

And why only (so far) two devices out of about 50?

The firmware (HAL) just wait for the hardware to clear ADC_CR_ADCAL bit.

This is why I'm suspecting a hardware failure...

Unless there is something wrong in the configuration, i will pursue the investigations.

Thanks

JYL

JLojo
Associate III

Of course I read this (old) post.

In our case, timeout is sooo long that there were not much doubt about that (nearly one minute)

Currently, in the H7 library, the timeout is set to:

/* At maximum CPU speed (480 MHz), this means                                   */
/*    1.32 * 480 MHz = 633600000 CPU cycles                                     */
#define ADC_CALIBRATION_TIMEOUT         (633600000U)   /*!< ADC calibration time-out value */

May be, just out of curiosity you can check ADC_CALFACT register value before calibration and after timeout if changed

JLojo
Associate III

0x0 for both ADC_CALFACT and ADC_CALFACT2 for both ADC, and both before and after calls to calibration!

Thus wondering if the calibration procedure is so useful...

Actually I thought I found the origin of the issue by reducing ADC clock speed.

It worked for a while at lower clock speed (was 32 MHz, reduced to 12MHz, which practically cannot be used operationally), but after the first power cycle was no more working... should have been just by chance.

I will definitely assume that this particular device has a broken ADC2...

What is your chip revision number ? Y or V ?

JLojo
Associate III

STM32H743VIT6

Pavel A.
Evangelist III

Do you generate the ADC init code with CubeMX/IDE?

There is (was) a bug in Cube-generated code for H7 ADC source clock config.

The latest CubeMX v. 6.6 should fix it. (I have not checked that yet)