H7 ADC Gapping - Voids in the digital output

[PWalt.2]

Hardware: H750 Revision V

Peripheral in Question: ADC 1 and 3

Capture rate: 860Hz

ADC Kernel Clock: 2Mhz

Channels Converted: 5

ADC Conversion overlap: NO

Transfer Protocol: DMA

ADC Conversion Trigger: TIM

We are using ADC 1 and 3 to capture analog pressure sensor readings. We observed a gapping phenomenon in the output data where the ADC failed to output data in specific ranges consistently.

We discovered that using the ADC_CALIB_OFFSET was incorrect and switched to ADC_CALIB_OFFSET_LINEARITY. We also calibrate every power cycle and account for temperature drifts. Despite all of this, on approximately 25% of the units we still see this gapping with the same version of firmware.

*Update - Adding in ADC Configurations via images

 

[AScha.3]

>> loss of precision will happen at low clock speeds , depending of the temperature and the leakage of all parts on the die, here the 0.1 pF caps, that must keep their charge to 1/65000 ( = 15 ppm); so not much time, until even many Mega-Ohm isolation will dischsrge in short time.

<<

depends on technology of the chip , but i would assume , that for faster chips the losses due to leakage currents are also higher .

[PWalt.2]

And the explanation of the process issue is that a slow clock speed could allow some of the capacitors of the SAR to discharge before the comparison and DAC operations are performed? I'm trying to get to an explanation of how the process fails. The gaps manifest in powers of 2 and happen when the least 4-8 significant bits are all ones and the next most significant bit jumps from a 0 to a 1.

[MasterT]

Reading your new findings regarding 4-8 LSB transition code, likely DNL error. Specification of the ADC in DS differentiate the packages,

"DS12556 Rev 6 161/336

1. Guaranteed by characterization for BGA packages, the values for LQFP packages might differ.

2. ADC DC accuracy values are measured after internal calibration.

3. The above table gives the ADC performance in 16-bit mode."

DNL is +3/-1 LSB. IMHO, I'd not expect great accuracy out of internal ADC, that is running in hostile uCPU digital environment.

Solution could be external IC or dithering+averaging LPF-ing.

[PWalt.2]

Here is a screenshot of the DNL for the 16 bit ADC. I am seeing +1.7/-1. I am assuming this means you can have a swing of +/- 2LSB worth of data. That doesn't seem to add up to the gapping we are seeing. Or am I misreading this? We don't need absolute accuracy, we just need to overserve all of the codes without gaps.

[PWalt.2]

Here is a spread sheet of when/where the gaps and clips occur. The numbers under the gaps are the minimum and maximum values around a gap. As in, the low number is the bottom of the gap and the larger number is the top side of the gap. This data was generated using a function generator and applying a triangle wave (see image in original posting).

[MasterT]

You are referring to AN5354, plz indicate next time what documents. Pay attention that "application note" is kind of different type compare to "Data sheet".

+3/-1 LSB I took out of DS12556 Rev 6 page 274.

Anyway, both values are "Typical".

When I read "Data guaranteed by characterization for BGA packages. The values for LQFP packages might differ." I fill like it's written by a lawyer or politician - not an engineer. Nothing to comment. Simply means you can observe any kind of misbehavior out of ADC, manufacturer has no idea and nothing guaranteed. With all due respect.

[waclawek.jan]

> Capture rate: 860Hz

This reminds me of the Wrong ADC result if conversion done late after calibration or previous conversion erratum for some STM32 (e.g. 'L431):

The result of an ADC conversion done more than 1 ms later than the previous ADC conversion or ADC calibration might be incorrect

I don't say this is the case in the 'H7 - after all it's an entirely different ADC, 16-bit and all - just want to highlight that doing things slowly around switched-capacitor designs may be problematic, too.

Note, that this is a user-driven forum with casual ST presence. You may want to contact ST directly through FAE or web support form. I believe this issue grants nagging ST a bit.

JW