What can cause an ADC calibration fails?

[JLojo]

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

[Michal Dudka]

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]

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

[Michal Dudka]

What about this ?

https://community.st.com/s/question/0D50X00009kLCgUSAW/bug-in-haladcexcalibrationstart

[JLojo]

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 */

[Michal Dudka]

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

[JLojo]

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...

[Michal Dudka]

What is your chip revision number ? Y or V ?

[JLojo]

STM32H743VIT6

[Michal Dudka]

That is part number, but not revision number. STM32H743xxx has two revisions (look at chip marking) called V and Y. Unfortunately they differ in many fundamental aspects (like max CPU clock or ADC clock and functions !) but share the same datasheet and reference manual (to confuse everybody). If you running code for V revision on Y revision chip, there can be lot of troubles.

[JLojo]

My mistake sorry.

Marking shows a 'V' just under the part number.

And reading DBGMCU->IDCODE gives  0x20036450 corresponding to a rev V device according to reference manual.

I saw indeed this distinction between rev V and rev Y in the reference manual, but didn't pay much attention about that.

It seems however that rev V can do more than rev Y, so it should not be a problem...

Thanks

[Pavel A.]

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)

[JLojo]

Code has been generated with the latest CubeIDE, that is V1.10.0 (12671_20220627_1643 ), featuring CubeMX V6.6.0-RC6 (202206222154).

And it works fine on 96% of the produced units...