stm32h750vbt6 adc 16bit 14bit issue

[mize]

Hello,

while using this mcu 16bit adc a strange thing happens.

the adc signal is test under a sinusoid signal(0.5Hz from a signal generator), and as shown in the figure at certain level adc keeps unchanged, after leaving this level then the signal increased again, however the trace has deviate from a standard sin signal.

as I checked the value is 0d57345 which is 0b1101 1111 1111 1111 and this phenomenen occurs everytime the 14th bits is 0 and lower bits are 1.(at 0b0001 1111 1111 1111, 0b0101 1111 1111 1111, 0b1001 1111 1111 1111 a value constant platform occurs)

and at some other points there is a leap where the trace goes back to original trace.

this happens for 14bits resolution adc sometimes as well.

sometimes for 15th bit as well.

I have tried several times to fix this including

1.longer sampling cycs

2.longer delay between conversion

3.independent mode/ dual mode(adc1, adc2)

4.LL LIB/HAL LIB

5.fast/slow adc clock

6.calibration/no calibration before enable and start conversion

7.fast/slow channel

none of above worked, so anyone have any idea please kindly reply

thanks

 

IOC file has been attached and my cube version is 6.12.0-RC9

 

 

[TDK]

Generally, this is caused by a poorly decoupled VDDA or VREF+ supply. Can you share your schematic/layout?

[mize]

 

Hi, this is my schematic diffierential signal pair from sensor amplified by ina8211dr then directly feed to MCU ADC channel.

There is one problem that I have disscussed with my hardware colleague that the capacitor between VDDA/GND and Vref+/GND is different with the AN2834 recommanded schematic that bypass capacitor with 1uf//1nf 1uf//100uf, but he says it won't affect too much, I'm not so sure about this for I mainly doing software, what's your opinion？ 

 

[mize]

and Vref+ is indenpent with VDDA

[STOne-32]

Dear @mize ,

 

if possible to share your hardware schematics : the exact MCU part number and package ,decoupling and which channels used . Here is an App Note on this 16-bits ADC and its performance. The input signal is also key to be very clean from a low noise source - using a standard lab generator and wires hooks at 16-bits should be carefully designed.

https://www.st.com/resource/en/application_note/an5354-getting-started-with-the-stm32h7-series-mcu-16bit-adc-stmicroelectronics.pdf

Hope it helps ,

STOne-32

[mize]

Hi,

  I have shared my relevant schematics in other replies, please refer to it. I tried two source, one was from designed sensor and amplified and one was directed from a signal generator device. So it is mostly a MCU problem, the chip I'm using is STM32H750VBT6 V 7837C VQ PHL 78 335  with QFP100 package, the VDDA and Vref+ are independently from different LDO and at different level. 

 I have tried fast channel 4,5 slow channel 7,8, and another MCU for I have 2 sample.

 

And as I have mentioned in other reply: There is one problem that I have disscussed with my hardware colleague that the capacitor between VDDA/GND and Vref+/GND is different with the AN2834 recommanded schematic that bypass capacitor with 1uf//1nf 1uf//100uf, but he says it won't affect too much.

So if you have any further idea please kindly comments, thanks a lot!

 

[MasterT]

From my experience with nucleo-H743zi2 board (stm32H743zi2) - all decoupling capacitors circuits designed by ST, and board manufactured by ST, ADC bits 12-13-14-15 are just noise. Doesn't matter how low source impedance of the inputs driver or what reference voltage is. IC package could be a cause.

 The only way to get 16-bits is using oversampling, running adc as fast as possible.

BTW, ad821 is powered by 5V may presents risk of damaging IC, consider 3.3V powered buffer for that. LM358 for reference is also wrong choice, OPA  has not sufficient GBW to drive switching capacitive load. In both sides - reference inputs and signal inputs good capacitance required to null out charge kickback interference. Look on google for correct SAR adc interfacing.

[mize]

HI，

@MasterT  @TDK  @STOne-32 

I have a hypothsis. The possible cause is that there is a voltage drop of 2-3mV (according to collected data presumably, something equavilent to the diode/transistor drive threshold voltage)  exists when comparing the 14th bit, and does not exist when comparing other bits,  thus causing the input voltage to comparator for bits 14 is lower than it should be.

 

STM32's SAR working flow is by charging the capacitor, reversing the input voltage to ground, and controlling different switches to obtain different voltage dividers to make the input voltage equal to -Vin+Vref voltage dividers, and then comparing the value of 0 with the comparator to obtain the ADC code.

here is some deduction, suppose the actual input voltage is V, and the drop value is Vd

1. for level flat phase, in the 14th bit of comparison, the external input voltage is V, but the input comparator voltage is V-Vd, where V14<V<V14-Vd, so the output value of V 14th bit is always 0.
   This voltage drop persists in successive phases after the levelling phase, and the actual input comparator voltage is V-Vd, so there is a fixed bias compared to the real voltage.(like in first figure)
2. after that, when V15 < V, the input voltage to the comparator is V when comparing V15, and 15th bit is encoding to 1, causing the voltage to leap directly from V-Vd to V( like in second figure)
3. until the next time, when  V14 <V-V15 <V14-Vd, the situation comes back at level flat phase, that happened again
4. For example, 32768 (1000 0000 0000 0000) is a number that can be successfully read, at this time it should be S1 connected to VREF, and other switches are connected to ground. The next time evel flat happens again, it is 40959 (1001 1111 1111 1111 1111), and the problem is 14th bit, and when comparing the 14th position, it is S1(bit16), S2(bit15), and S3(bit14) connected to Vref, so the guess here is that S3(bit14) makes a voltage drop when it connected to VREF, and this is the only situation where voltage drop exists, so that the input voltage is less than the actual voltage, resulting in the abnormality of the ADC

 

however it is impossible for me to check the design inside MCU (like the e-switch type is in use) , so this only will be a theory. I have attached a data record for reference. enjoy&thx

[PGump.1]

Hi,

I haven't read all the notes here, however, I did see a LM358 as your buffer... This is most likely where your problem is. If it is too difficult to change the LM358, then put a 10K resistor from the output to ground - this should fix (improve) it.

KInd regards
Pedro

[mize]

hi,

I made a mistake before, the LM358 is not for generating VREF+ for MCU ADC, it generates ref voltage for INA821IDR, which amplifies the differential signal from sensor.

A TL431AIDBZR connecting cathode and ref generates 2.5V reference voltage Vref+. However, I check TI LM358 data sheet, and didn't find a reference application that a 10K R is necessary. could you give me detail about the purpose of bypass resistance？

best

[PGump.1]

"could you give me detail about the purpose of bypass resistance"  - NO!

I can't be bothered cleaning my scanner for this issue.

Everyone who has used a LM358 for the last 60 years knows that they have nice step in their output (just like the one you posted) as they attempt to change from Push to Pull (and vice versa) on their output. Putting the 10k resistor on the output to ground keeps it in the Push state...

Kind regards
Pedro

[lura]

Hi,

I don't know if it's relevant anymore, but we ran into similar problems with ADC2 on STM32H753. Regardless of which calibration routine and parameters we used, we ended up having jumps and/or flat regions in our ADC data (testes with a slow linear ramp analog signal).

Investigating the ADC linear calibration data, we did a bit of guess work and set the linear calibration parameters manually, where each of the 16  10-bit-values  is set to  0x200:

 uint32_t lincalbuf[ADC_LINEAR_CALIB_REG_COUNT] = {
		 0x20080200u,
		 0x20080200u,
		 0x20080200u,
		 0x20080200u,
		 0x20080200u,
		 0x00000200u,
 };
 HAL_ADCEx_LinearCalibration_SetValue(&hadc2, lincalbuf);

(Rationale: reading the linear calibration values, the 10-bit segments always lay around 0x200 +/- 0x20; thus we assumed that 0x200 may be some "neutral" value.
Packing: Each of the first five 32-bit calibration words contain three 10-bit values each, and lincalbuf[5] contains the remaining one.)

Perhaps this scheme may work for you, too?