STM32H7 ADC performance - ya gotta read the fine print!

[splin]

The STM32H7 has possibly the best (specified) fast ADCs of any MCU with 3 x 3.6MSPS 16 bit SAR ADCs with hardware oversampling:

ENOB  13.2
DNL    14bit equiv (differential linearity, equivalent to a 14bit ADC with 1 bit DNL)
INL     13bit equiv (integral linearity).
THD    -90dB

Impressive; Ok, the LPC4370 has an 80MSPS 12 bit ADC with approx 10 bit ENOB but < 11bit equiv INL, -73dB THD and only one ADC. If you want to oversample it's going to consume a lot of CPU.

But as always you need to read the fine print; the latest silicon is revision V replacing revision Y so look in 7.3.20 of the datasheet. Not unreasonably there are some qualifiers for 16bit, 3.6MSPS operation - VDDA > 2.5V, Tj = 90C (rather than 125C). Fair enough, but with the revision V datasheet comes the new qualification that this applies to 'direct channels'. Hmm, so what are they? They are 2 or 4 (depending on package) dedicated IO pads with low impedance paths to the ADCs selectable by 4 bits in the SYSCFG_PMCR register.

Hmm - but to get 13.2 bit ENOB performance you have to use the ADCs in differential mode which means that only two signals can use these direct channels so the third would have to use a 'fast channel' at 2.9MSPS max. But one pair of direct channels goes to both ADC1 and 2 allowing you to sample one signal at 7.2MSPS with ADCs 1 and 2 in dual interleaved mode so technically you can sample at 3 x 3.6MSPS but with only 2 signals which might suit your needs.

But there's a 'gotcha' of course and in this case only the 240 pin BGA package provides 4 direct channels - the 169 and 176 pin BGA, WLCSP and all LQFP packages only provide the 2 direct channels to ADC3. Why on earth didn't they provide the ADC12 direct channels instead since the whole point of them is for high performance?

Ok, the TFBGA240 package is .8mm rather than the .35mm WLCSP156, .5mm UFBGA169 and .65mm UFBGA176 packages so you can at least use cheap PCB fabricators. Unfortunately the cheapest TFBGA240 is the STM32H750XB at $4.77 (@10k) compared to $3.69 for the LQFP100 STM32H750VB that you might have been planning to use.

So far, not too bad a compromise - an extra $1 or so for a BGA version, but maybe you can use the extra IO. But check the small print a bit more closely - specifically:

'3. These values are valid for UFBGA176+25 and one ADC. The values for other packages and multiple ADCs may be different.'

Alarm bells!!! Don't bother searching the datasheet for elucidation. But this presentation provides some insight:

https://www.stmicroelectronics.com.cn/content/ccc/resource/training/technical/product_training/group0/3c/ee/54/92/43/f1/4e/27/STM32H7-Analog-ADC_ADC/files/STM32H7-Analog-ADC_ADC.pdf/_jcr_content/translations/en.STM32H7-Analog-ADC_ADC.pdf

Specifically page 11:



There's nothing in the presentation that shows how the number of ADCs in use effects performance but the package has a massive impact; you can get 3.6MSPS but only using the UFBGA169 which only provides one differential direct channel. The TFBGA240 apparently only achieves 2.5MSPS, which to be fair is still pretty good, but presumably only if you are only using one ADC. Use a LQFP208 package (and also, presumably, the cheap LQFP100 version) and it seems you only get 1MSPS!! That presumably is for the direct channels so maybe the 'fast' channels are even worse?

Maybe that presentation is out of date but I doubt it's far off the mark. MCU ADC specs are always a bit of a minefield and to their credit ST do provide some of the most detailed ADC specs. Microchip came a bit of a cropper with their PIC32MZ ADCs which didn't remotely meet expectations, but they did admit to that and downgraded the datasheet specs. In the case of the STM32H7 parts I think that the huge disparity between the headline claim of 3 x (up to) 3.6MSPS ADCs and the 1MSPS for one ADC that we might now expect for most devices is almost fraudulent given that the training presentation clearly shows they know how the ADCs perform yet the recently released (November) STM32H750 datasheet almost totally ignores the package impact apart from that seemingly innocuous footnote.

You could expend a lot of time and money in a project before discovering the impact of that footnote which could easily render that project unviable. Yes it's your responsibility to verify the performance of a part that you have selected meets the claims but the datasheet should include all the relevamt data in an accessable form and you should expect it to be reasonably close to reality if it isn't labelled 'preliminary'. Hopefully ST will fix this soon but I'm not holding my breath.

Has anyone here evaluated the H7 ADCs and is free to provide some results?


PS. I see Microchip are making this absurd claim in AN2785 "World's Fastest Embedded Interleaved 12-bit ADC Using PIC32MZ and PIC32MK Families":

http://ww1.microchip.com/downloads/en/Appnotes/Worlds-Fastest-Embedded-Interleaved-12-bit-ADC-Using-PIC32MZ-and-PIC32MK-Families-DS00002785A.pdf

The PIC32MZ and PIC32MK device families have an advanced Class_1 12-bit ADC with features that enable them to be interleaved such that the composite ADC through-put rate can far exceed any individual ADC through-put rate

20MPS @12 bits "far exceed any individual ADC"? Well maybe any Microchip ADC perhaps. It seems the claimant didn't bother to put much effort into researching the market. NXP should be justifiably miffed at the claim that 20MSPS achieved by 6 interleaved 12 bit ADCs in a PIC32MK comes anywhere near the LPC4370's 80MSPS ADC.

[EDIT] Added missing image

[thm_w]

That chart is  really surprising, even at 12-bit you are seeing close to 3x performance difference between TQFP and BGA.
I wonder if this applies to other parts as well. I rarely see it mentioned, unless its something obvious like thermal resistance variation or stability based on package.

[splin]

That chart is  really surprising, even at 12-bit you are seeing close to 3x performance difference between TQFP and BGA.
I wonder if this applies to other parts as well. I rarely see it mentioned, unless its something obvious like thermal resistance variation or stability based on package.

Yes it's quite extraordinary - major kudos to ST for publishing the information; major <opposite of kudos> to ST for not declaring the information in the November 2019 datasheets. To be fair the presentation may have been based on early silicon/packaging - its quite possible they have made major improvements subsequently.

Obviously, all manufacturers have their dark secrets they don't care to share with the world; often publishing specs with typical values only or such wide limits that you have no idea what might actually be delivered.

The most obvious candidates for the package impact is parasitic ground impedance (principally inductance?) which would also cause degredation as the number of ADCs in use increases. Precision analog electronics are not good housemates with high speed digital circuits.

Hopefully ST will provide better information eventually as the ADCs are (for me at least) the flagship peripherals.

[MasterT]

I bought nucleo-H743zi about a year ago, expecting to have nice adc for analog/ metrology project. My evaluation was complete disaster, hardly get 10-bits of ENOB ( same value I had with arduino UNO significantly overdrawing adc at 80 ksps). All my efforts experimenting with SE/ DIFF inputs, non and buffered,  different sampling rate, synchronous-clock vs asynchronous - nothing helped. IC revision 1003 (Y). I only thought that reference voltage soldered directly to VDDA ( and to VDD) is possible cause. This month I get next revision, nucleo-H743zi2, IC 2003 (V), reference voltage and VDDA -> jumpered, so I removed "0" R and was hoping for miracle. Miracle didn't happened. ADC is a crap, worse than I could imagine, 8-bits ENOB.
 Have nothing against STM, have a bunch of their nucleos -F3, F4, F7, H7, L4, and even new G-4 (isn't tested yet), great boards. All goods, peripheral and math (float), fast CPU, good flexible timers. Even DAC's are not so bad, could run at 24 MSPS (! H7) and outputs -90 dBC THD.  Except ADC. Buy external, I have analog d., for example, ad7983 module, 1.333 msps 16-bits. Verification proofs 15.8 bits ENOB with 100 kHz sine wave.

[iMo]

Some time back there was a pretty long thread (at ST's forum) a guy messed with stm32's ADC, claiming the ADC unit is a crap. STM claimed the ADC datasheet parameters are ok.
In the end the guy finally designed 4 layer board and confirmed it works as expected.
Here the guy points at the STM forum where you may find the thread:
https://electronics.stackexchange.com/questions/21452/stm32-adc-noise-2

[OwO]

Well I've never had any problems getting ~11 ENOB on cheap stm32f103s (probably not even genuine ones). The noise is usually 1LSB pk-pk with the input biased to the center.

[iMo]

1LSBp-p is a great result - how did you do it?

[Yansi]

I bought nucleo-H743zi about a year ago, expecting to have nice adc for analog/ metrology project. My evaluation was complete disaster, hardly get 10-bits of ENOB ( same value I had with arduino UNO significantly overdrawing adc at 80 ksps). All my efforts experimenting with SE/ DIFF inputs, non and buffered,  different sampling rate, synchronous-clock vs asynchronous - nothing helped. IC revision 1003 (Y). I only thought that reference voltage soldered directly to VDDA ( and to VDD) is possible cause. This month I get next revision, nucleo-H743zi2, IC 2003 (V), reference voltage and VDDA -> jumpered, so I removed "0" R and was hoping for miracle. Miracle didn't happened. ADC is a crap, worse than I could imagine, 8-bits ENOB.
 Have nothing against STM, have a bunch of their nucleos -F3, F4, F7, H7, L4, and even new G-4 (isn't tested yet), great boards. All goods, peripheral and math (float), fast CPU, good flexible timers. Even DAC's are not so bad, could run at 24 MSPS (! H7) and outputs -90 dBC THD.  Except ADC. Buy external, I have analog d., for example, ad7983 module, 1.333 msps 16-bits. Verification proofs 15.8 bits ENOB with 100 kHz sine wave.

Using a POS nucleo board layout for analog performance evaluation is major fuckup from the beginning. 

[OwO]

1LSBp-p is a great result - how did you do it?

Nothing fancy, just 4L board and solid ground plane on in1 (layer directly below top). The ADC sees the voltage difference between VSSA and VIN, so connecting VSSA to a quiet point in the ground plane and also routing the VIN trace above quiet parts of the ground plane + via fencing should do it. Also on a 4L board the best power supply bypassing you can do is capacitors on the bottom of the board under the VDD pin. A common misconception is that a power plane provides better decoupling but on 4 layers the planes are too distant for there to be enough capacitance and you risk creating resonances if the caps are too far away.

[OwO]

The other thing I like to do at ADC inputs is have a R-C filter, with the C being physically close to VIN. The frequencies we are talking about here are essentially DC so we can pretty easily remove all the higher frequency nasties. A RC filter of 100ohms + 100pF, having a corner frequency of 45MHz, will still do wonders for noise suppression and will have the additional benefit of better EMI immunity. Since we are talking DC, we can even remove power supply noise by simply nulling it (e.g. you have a signal source that is corrupted by power supply noise. You amplify the signal with op-amps, and by feeding the correct amount of power supply noise to the inverting input you can subtract away the noise). I used this method in one application because cleaning up the power supply with a linear regulator was not an option and noise < 1MHz can't be filtered out with ferrite beads.

[MasterT]

Some time back there was a pretty long thread (at ST's forum) a guy messed with stm32's ADC, claiming the ADC unit is a crap. STM claimed the ADC datasheet parameters are ok.
In the end the guy finally designed 4 layer board and confirmed it works as expected.
Here the guy points at the STM forum where you may find the thread:
https://electronics.stackexchange.com/questions/21452/stm32-adc-noise-2

What I see, is a "granularity" in the samples pull. Printing block of the raw data , there is noticeable jumping +-32 , seems like someone put 11-bits adc and than extend resolution to 16-bits. I spent some time to fight a noise, that "masks" granularity effect. pretty close to discussion in the pointed thread.
I changed the clock HSE, from 8 MHz (RC based) to 50 MHz (crystal)
https://community.st.com/s/question/0D50X0000BiD6fISQS/stlink-provides-808-mhz-instead-of-8000-on-new-nucleoh743zi2
50 MHz is visible in the output of adc data processed by fft, about -40 dBc aliasing to 1.8 MHz range, though if internal OPA is used as a buffer interference drops to -60 or so. But OPA itself was not design to evaluate 16-bits ADC, and creates -50 second harmonics - very likely not capable to drive switching capacitive load. Certainly parameters of the OPA are far away from ad4841.

[thm_w]

Some time back there was a pretty long thread (at ST's forum) a guy messed with stm32's ADC, claiming the ADC unit is a crap. STM claimed the ADC datasheet parameters are ok.
In the end the guy finally designed 4 layer board and confirmed it works as expected.
Here the guy points at the STM forum where you may find the thread:
https://electronics.stackexchange.com/questions/21452/stm32-adc-noise-2

Interesting, it sort of makes sense based on those PCB images, look at the ridiculous number of traces coming off the IC from the bottom and the top. Can't see much of a ground plane. The "fix" to solder some heavy ground wires on the back, its good but its not shielding.
Maybe a much simpler design with a completely solid bottom ground can get away with it.

[MasterT]

STM32H7 has different ADC structure, likely two stages SAR. There is no info in DS, but they can't complete 16-bits conversion in 8 clock of ADC.  All those F2/F3/F4  needs 12 clock for 12-bits, plus 2.5 sampling-hold time so it's usually rounds up to 15.  H7  works in 8 + 1.5 S/H = 10 clock.  And probably, something went wrong with two stages, offset or "sticking bits" .  I'm running bit statistics analysis right now, don't want to invent a bike but google doesn't see a difference in kind of adc and doesn't  help on finding right method.
 Is there some kind of technics  for "granularity" test except histogram?

[OwO]

STM32H7 has different ADC structure, likely two stages SAR. There is no info in DS, but they can't complete 16-bits conversion in 8 clock of ADC.  All those F2/F3/F4  needs 12 clock for 12-bits, plus 2.5 sampling-hold time so it's usually rounds up to 15.  H7  works in 8 + 1.5 S/H = 10 clock.  And probably, something went wrong with two stages, offset or "sticking bits" .  I'm running bit statistics analysis right now, don't want to invent a bike but google doesn't see a difference in kind of adc and doesn't  help on finding right method.
 Is there some kind of technics  for "granularity" test except histogram?

Yes, differential non-linearity, which for the F103 is specified to be +/-1 LSB and ~5 LSB for the H750. If you are seeing missing codes it might be something wrong with the clocking or configuration, not noise at the input.

[iMo]

fyi pretty good analysis:
https://community.st.com/s/question/0D50X00009sV2JSSA0/fluctuations-in-adc-value-of-stm32h743-mcu

[Harjit]

fyi pretty good analysis:
https://community.st.com/s/question/0D50X00009sV2JSSA0/fluctuations-in-adc-value-of-stm32h743-mcu

Very interesting and good piece of work - the problem turned out to be noise from the Ethernet phy.

[mbless]

Has anyone here evaluated the H7 ADCs and is free to provide some results?

Did you ever go through with using an H7? I'm looking into using one now and am curious how it went.

[mbless]

That chart is  really surprising, even at 12-bit you are seeing close to 3x performance difference between TQFP and BGA.
I wonder if this applies to other parts as well. I rarely see it mentioned, unless its something obvious like thermal resistance variation or stability based on package.

They released app note AN5354 in March 2020 addressing this. Section 3.2 says the lower pin inductance of BGA packages allows the reference voltage to settle faster. They also give Table 12 with max ADC clock for various packages, number of ADCs and resolution, and break down all the numbers (error, ENOB, etc.) for the different resolutions.

[DEHiCKA]

They released app note AN5354 in March 2020 addressing this. Section 3.2 says the lower pin inductance of BGA packages allows the reference voltage to settle faster. They also give Table 12 with max ADC clock for various packages, number of ADCs and resolution, and break down all the numbers (error, ENOB, etc.) for the different resolutions.

And still it does not add up.
They claim in section 4.2: 7 Ms/s 16-bit dual interleaved.
How? BGA169/176 does not have direct channels on ADC1/2.
So, without performance degradation max bitrate will be only 2.73*2 = 5.46 Ms/s, not 7 Ms/s.
For 14-bits it is even worse - 7.2 Ms/s vs 10 Ms/s.
Same goes for other max bit rates in triple or dual modes.

[mbless]

Agreed, their numbers don't make sense or apply to all parts. I'm looking at the H750 in the BGA 176 package. There are 2 direct channels but on the same ADC, so I think I can get faster sampling by using fast channels on separate ADCs and interleave them.

[Boscoe]

Other than reading a pot or some input voltage I don't use the ADCs built into the MCUs.

It's scary what the manufacturers are aware of being a problem and don't even document it. The SPI 3 wire on the STM32L431RB (and maybe others) is completely broken, after really pushing with ST engineers directly they finally admitted it but it's not documented anywhere. The fix was an awful hack involving disabling ALL interrupts to TX/RX data on SPI!

I've had some other horror stories with other manufacturers and their parts.

[DEHiCKA]

I'm looking at the H750 in the BGA 176 package. There are 2 direct channels but on the same ADC

It is the same for all H74x/H75x BGA169/176, direct channels only on ADC3.

They have corrected this mistake in new H72x/73x series though. 16-bit ADC1/2 now share the same 2 direct channels.
But the AN5354 is for H74x/H75x, not H72x/73x.

And H72x/73x ADC3 is 12-bit only, so 14/16-bit data rates for triple mode still not achievable.

[aandrew]

You amplify the signal with op-amps, and by feeding the correct amount of power supply noise to the inverting input you can subtract away the noise

I'm having some trouble visualizing this; Can you elaborate?

[pravardhan]

Hi,

We are facing some issue in ADC1 & ADC2 which are getting failed in few boards.
 
We are using STM32H747IGT6 micro-controller (MCU) in one of our custom board. This MCU was suggested by our customer only for their product.
 
We have till now produced more than 45 boards.

In the 3 of the assembled 25 boards recently, we faced an issue with the ADC1 & ADC2 not being initialized but ADC3 was getting initialized.

Our embedded team pointed that the MCU was getting stuck at the below error:
#define HAL_ADC_STATE_ERROR_INTERNAL  (0x00000010UL) /*!< Internal error occurrence */

We had checked all the analog voltages - VDDA (Pin-40), VREF+ (Pin-39) & VSSA (Pin-38) and ferrite beads. All these voltages were ok.
Later when we replaced the MCU in two boards, all the ADCs are working fine in these two boards.

Also in the below ST Community, one user say that he is also facing the same ADC Init error HAL_ADC_STATE_ERROR_INTERNAL
& also says that the MCU is not gone bad due to ESD or wrong handling of the boards.
But another user say that the ADC in MCU was broken & had to replace the MCU.

https://community.st.com/s/question/0D50X0000BbNnCjSQK/stm32h7-hal-adc-with-dma-init-ends-in-errorhandler-cubemx

Is there any manufacturing defect or a bug in the ADCs of this STM32 MCU ?
Or are we not doing the initialization properly ?
Is there any bug in the HAL library for ADC ?
 

Thanks & Regards,
Pravardhan U.S

[peter-h]

I've been using on-chip ADCs since the H8/323 (1995 or so) and have always found the last few bits are basically noise.

To get 16 bits you need a dedicated chip and very good PCB layout and probably shielding (with a metal cover over the circuit) and some kind of BNC/SMA type input connector. And a reference costing a few quid.

I would be amazed if this ADC delivered 12 bits of real data with the CPU running normal code. With the CPU in some sleep mode during the measurement, it is a lot easier. On the 32F417 12-bit ADC you get about 10 bits.