Bug in HAL_ADCEx_Calibration_Start

[Kilian Nötzold]

The function using ADC_CALIBRATION_TIMEOUT. This timeout is defines as:

/* Fixed timeout value for ADC calibration.                                   */
/* Values defined to be higher than worst cases: low clock frequency,         */
/* maximum prescalers.                                                        */
/* Ex of profile low frequency : f_ADC at 0.35 MHz (minimum value             */
/* according to Data sheet), calibration_time MAX = 112 / f_ADC               */
/*           112 / 350,000 = 0.32 ms                                           */
/* At maximum CPU speed (200 MHz), this means                                  */
/*    0.8 ms * 200 MHz = 64000 CPU cycles                                      */
#define ADC_CALIBRATION_TIMEOUT         ((uint32_t) 64000)   /*!< ADC calibration time-out value */

The CPU speed is 400Mhz for the H7 so the timeout is to small. In my case f_ADC =36Mhz, f_CPU=400Mhz it need to be at least 115000. I just doublet it and it is fine.

HAL File: stm32h7xx_hal_adc_ex.c

HAL Version:  V1.3.0

Just want inform STM so they can fix it for all of us.

[AvaTar]

At the risk of repreating myself - this speaks volumes about the level and extent of testing.

[Amel NASRI]

Hi @Kilian Nötzold​ ,

Thanks for highlighting this issue. It is tracked internally to be fixed in coming versions of STM32CubeH7 package.

-Amel

[Garnett.Robert]

Yes Avatar.

I agree with your comment about testing. I am constantly having to fix HAL driver code. An example is the driver for the SPI bus. This is a snippet of code for the TransmitReceive SPI Bus DMA driver. If you leave it in you cannot get the SPI bus to handle any of the various data length combinations that are supposedly available. I wanted to send 32 bit words with 32 bit CRC. If I left this code in it wouldn't work. Comment it out and it works perfectly. It could never have worked and thus was never tested. I tried a number of combinations of frame lengths with this code in place and nothing worked.

I didn't bother to report it as there doesn't seem to be any single place of responsibility that manages the HAL drivers and interfaces with us developers. I'm happy with the HAL Drivers as a concept, unlike a lot of others I think the idea is much better than the old Standard Peripheral drivers, but the testing is abysmal and there doesn't seem to be eny way of getting things fixed.

It's like the people who write the HAl drivers are thousands of miles away from the chip developers.

I just had a look at the latest relaease of f HAL for the H7 and the cal timeout issue hasn't been fixed.

ST are really letting us down.

// rjg
//  /* Packing mode management is enabled by the DMA settings */
//  if (((hspi->Init.DataSize > SPI_DATASIZE_16BIT) && (hspi->hdmarx->Init.MemDataAlignment != DMA_MDATAALIGN_WORD))    || \
//      ((hspi->Init.DataSize > SPI_DATASIZE_8BIT) && ((hspi->hdmarx->Init.MemDataAlignment != DMA_MDATAALIGN_HALFWORD) && \
//                                                         (hspi->hdmarx->Init.MemDataAlignment != DMA_MDATAALIGN_WORD))))
//  {
//    /* Restriction the DMA data received is not allowed in this mode */
//    errorcode = HAL_ERROR;
//    /* Process Unlocked */
//    __HAL_UNLOCK(hspi);
//    return errorcode;
//  }

[Amel NASRI]

Hello @Kilian Nötzold​ ,

Please note that the error you reported is fixed in STM32CubeH7 V1.4.0 already available on the web.

-Amel