ADC - Only half of the programmed sample rate (specs changed).

[Rob vdH]

Hi folks,

Today I discovered a nasty little change in the clock handling of the ADC converter. It turns out that between revision Y and revision V of the STM32H7 they fixed ADC conversion problems by inserting a /2 clock divider between fADC and the ADC. (See AN5312). This effectively halves the maximum sample rate of the ADC.

I consider this a breaking change that makes the STM32H7 useless for my application. Still I need a MCU that can do 14 bit ADC at 4MSPS. Are there *stable* STM chips that can do this?

Kind Regards,

Rob.

[TDK]

It is possible to determine the chip revision programmatically and adjust the ADC clock accordingly, if you want to consider that.

> Still I need a MCU that can do 14 bit ADC at 4MSPS. Are there *stable* STM chips that can do this?

Not even the H7 series can do that. From the datasheet:

> 3× ADCs with 16-bit max. resolution (up to 36 channels, up to 3.6 MSPS)

And I'm guessing that 3.6 Msps is not at 14 bit resolution.

[Rob vdH]

3.6 Msps is at 16 bit resolution.

For 14 bit resolution the total conversion time is 9 clocks.

With fADC at 36 MHz it should give a sample rate of 4Msps.

I tried doubling fADC to 72 MHz, but then the ADC gets a clock-prescale of 2.

(factor 1 is not available anymore) which of course does not help.

[TDK]

> 3.6 Msps is at 16 bit resolution.

You're right. Interestingly, the max rate appears to be package-dependent:

Are you interfacing with registers directly or are you using HAL to accomplish the setup?

[Rob vdH]

Interesting tables, thanks!

I bought a Nucleo H745ZI-Q development board to learn about STM32 programming.

In order to flatten the learning curve, I only use the HAL functions...

Also, I use the STM32CubeIDE for programming.

My board seems to be fitted with the LQFP144 package.

So at 4 Msps, 10 bit is the best it can do...

[Rob vdH]

Investigated the strange /2 ADC clock divider a bit further and inside the ADC_ConfigureBoostMode function I came across the following code:

else /* STM32H7 silicon Rev.V */
  {
    freq /= 2U; /* divider by 2 for Rev.V */
 
    if (freq <= 6250000UL)
    {
      MODIFY_REG(hadc->Instance->CR, ADC_CR_BOOST, 0UL);
    }
    else if (freq <= 12500000UL)
    {
      MODIFY_REG(hadc->Instance->CR, ADC_CR_BOOST, ADC_CR_BOOST_0);
    }
    else if (freq <= 25000000UL)
    {
      MODIFY_REG(hadc->Instance->CR, ADC_CR_BOOST, ADC_CR_BOOST_1);
    }
    else /* if(freq > 25000000UL) */
    {
      MODIFY_REG(hadc->Instance->CR, ADC_CR_BOOST, ADC_CR_BOOST_1 | ADC_CR_BOOST_0);
    }

The /2 prescaled frequency seems to have the same range as Rev Y. So, I think it's safe to simply double fADC to get the correct sample rate. CubeMX does not know this, and sets the wrong ADC clock prescale every time I use it :-(.

I think the /2 divider was not added to limit the ADC sample rate, they probably needed a clock signal with double the frequency inside the ADC circuit.

[TDK]

Thanks for tracking that down and reporting back.

In typical software development fashion, it's pretty clear the STM32CubeMX team is separate from the HAL team and it doesn't seem like the communication is awesome between the two.