ST 32F417 ADC1 or ADC2 input impedance

[peter-h]

This is a massively complicated part of the 32F4xx and you can spent days just working out how to configure it.

So this is just a quick Q in case somebody has been there before.

In the data sheet, page 137-139, it states Zin max is 50k. Then it gives a formula for determining the max Zout of whatever is driving the ADC input if you want the error to be below 1 LSB.





It is a 12-bit SAR with a sample and hold so it is fairly obvious why Zin is directly related to a) the ADC clock and b) the setting for how many clocks is each sampling period.

All switched-cap converters (SAR or delta-sigma) have this issue that whatever is driving the input is having to charge the capacitors...

Now, if I plug the slowest possible values into the formula, I get some silly value suggesting that if you run the ADC at the slowest possible (0.6MHz) and have the longest possible sampling period (ADC_SMPR = 480 clocks) then you should get a very large Zin; many Mohms.

So where does the 50k Zin come from? Have they got a 50k resistor to GND?

As usual with ST chips, the internet is full of people asking these questions but most of the answers are meaningless.

We are running at 168MHz so a 0.6MHz ADC clock may not be possible but I haven't got that far yet

Any input much appreciated.

[thm_w]

https://electronics.stackexchange.com/questions/311967/how-to-have-an-accurate-adcstm32?rq=1
https://community.st.com/s/question/0D50X0000A7YRQ1SQO/question-about-stm32f407-adc-input-impedance
http://cholla.mmto.org/stm32/blue_pill/adc/an2834.pdf

In the first link you can see a diagram of the ADC input pin. There is no pull up or pull down resistance unless you have specifically enabled them. You can also see a symbol for input leakage.
The input leakage spec should be "+/- 1uA on 3.3V inputs and +3uA on 5V tolerant inputs".

So I assume 50k is the maximum value where leakage is not an issue, once you get into the MOhms, 1uA leakage will result in a very large offset.

[T3sl4co1l]

"I'm not locked in here with you, you're locked in here with me"

Well, "locked" isn't the right adjective, but the reversal is.

They're not telling you what equivalent load resistance the ADC has.  It's high, many megs typically.

They're telling you what you need to present to it: the source resistance.

As long as you're under that limit, samples will be accurate (capacitor voltage stabilized to input).

Additionally, it may be that repeated acquisitions approach the same result anyway.  It's not obvious if there would be bleed-through from the mux, as the ADC capacitor ends up charged to different sources in turn.  (I have seen this happen with an external mux and high impedance sources; YMMV.)

If that happens, simply change the mux, sample it a few times, and discard the first sample or two.

And, check the errata.  Some of the STM32 parts are notorious for glitches coincident with certain internal functions.  I don't remember which offhand, or if this part is affected.  Others can chime in with direct experience.

Tim

[Siwastaja]

There is DC leakage, albeit small.

Say, if the ADC has internal 5Mohm equivalent leakage (either towards Vdd or GND, doesn't matter), external (your circuit!) 50kOhm forms a divider causing a 1% error already!

Hence even if you could configure infinitely long sampling to completely remove the error caused by internal C_sampl charging through R_external, the voltage divider R_internal_leak and R_external remains. R_external = 50k max seems a very good idea, although I would go for something much smaller than that if accuracy is important.

[peter-h]

Thank you all for your input. I saw those links. Actually I think there is a mistake in the 1st one, where it states that a high value for Cparasitic will downgrade conversion accuracy. Surely, a big cap across the input will always help with charging up the ADC's internal capacitors - if you can tolerate its other effects

But my Q is regarding a really basic principle. What I am doing right now is feeding the ADC input from a potential divider, two 10k resistors, between GND and the +3.3V rail. The purpose is to measure the +3.3V rail, to say within 3%. The 32F is a 100 pin package so I have the Vref+ pin available, and it is fed from a TL431A which is 2.5V 1%.

The 1uA input leakage would be immaterial to the above, with a 5k source impedance feeding the ADC.

I am just not getting sensible values out of that formula, for the slowest possible ADC operation, and the 50k value in the data sheet doesn't compute from anything e.g. the 1uA leakage (which, crudely translated, would be 3.3M with a +3.3V input, not 50k). The 50k is specced as the input impedance, not the max source impedance for 12 bit accuracy. Anyway, one would never specify a leakage current as a resistance.

If Zin really was 50k (max!) then the ADC would never be usable to anywhere near 12 bits without an op-amp driving it. You would need Zout of a few ohms or less.

I am not after ~12 bit accuracy. If I wanted that, I would use a precision op-amp to drive the ADC, probably a TLV2333 or similar auto-zeroing one. One has to do that with all the switched-cap devices, most of the time.

[Siwastaja]

It says pretty clearly EXTERNAL input impedance. That refers to the maximum value of YOUR external resistor, not Zin of the ADC. It makes sense to me, the formula calculates the AC behavior, the 50k is recommended based on DC leakage, the final resistor will be whichever gives the smaller result.

That being said, ST documentation is a joke, I wouldn't even consider looking at any formula describing analog behavior they give. It may be OK or may be total bollocks.

If you are interested in the ADC performance, you have to measure it.

Capacitor is cheap, simple and OK for DC signals, 100nF would be typical, just remember to limit the sample rate! Each sampling consumes charge and if the resistor divider is large, there will be an error.

[hans]

The ADC samples the input voltage onto a sampling capacitor through a finite impedance R, which consists of the switch resistance and the external impedance. You can derive the Rin max equation using a RC circuit, where we have:

C = sampling capacitor inside the ADC
R = the series resistance of the sampling switch plus the external impedance you have from your voltage source
t = the time in which the voltage on C has to be settled (e.g. t = k - 0.5 cycles at f_ADC). I guess that the half cycle subtraction of k is some propagation delay, or perhaps the switch is set on the falling edge of the ADC clock.
Vin = the supplied input voltage
Vc = the output capacitor voltage voltage for the ADC.

You can then use the RC series circuit time-domain equations to solve:

Vc=Vin*(1- exp(-t/(R*C)))

Note that we need Vc to approach 1/4 LSB away from Vin in t time (where t is the sampling time). 1 LSB at 12-bit (N=12) is 1/2^12 part. 1/4 LSB means a further 1/4 part (which is 1/2^2), which combined gives 1/2^(12) * 1/2^2 = 1/2^(12+2).
We need this small fraction to be away from charging Vc up to 100% of Vin, e.g. we need the final capacitor value to be at 1 - 1/2^(12+2). Therefore we need to have Vc=Vin * (1 - 1/2^(N+2)) level, with N is the number of ADC bits. We can plug this into the RC equation and  divide both sides by Vin:

1 - 1/2^(N+2) = 1 - exp(-t/(R*C))

Then try to solve for R. Rewrite 1/x^a = x^-a, then remove 1-x both sides, then apply inverse of exp() with ln(), finally rearrange:

1 - 2^-(N+2) = 1 - exp(-t/(R*C))
2^-(N+2) = exp(-t/(R*C))
ln(2^-(N+2)) = -t/(R*C)
R=-t/C/ln(2^-(N+2))

Finally we can use t = (k-0.5)/f_ADC and ln(2^-x) = -ln(2^x):

R=(k-0.5)/f_ADC/C/ln(2^(N+2))

Herein R is the total series resistance, which includes the internal sampling switch, so with R=R_EXT + R_ADC:

R_EXT=(k-0.5)/f_ADC/C/ln(2^(N+2)) - R_ADC

Which is the same equation as from the datasheet.


Theoretically this is correct. k can be as low as 3 cycles for high-speed ADC operation, however if you C=4pF, f_ADC=30MHz and R_ADC=6k ohm, then you get R_EXT <= -3.9k ohm for a 12-bit conversion. The datasheet then specifies that R_ADC maximum is given for when VDD=1.8V, however it doesn't give the typical or minimum when VDD=3.3V. Conclusion: it's a gray area... good advice from Siwastaja to just build it, measure it and fine tune.

Note that if you slap a large external sampling capacitor while still using a high source impedance, you're effectively also creating a low pass filter. E.g. R_EXT=10k ohm and C_EXT=100nF, then f_-3dB = 15.9Hz

[peter-h]

Super many thanks!

Is anyone able to work out the scenario for the ADC when running as slowly as possible e.g. max prescaler and max clocks per sample?

It seems to me that it really is a very high impedance - at least in the Mohms range.

In many applications one doesn't need a fast ADC.

Another thing, which I find hard to understand why it would not apply to this ADC: every on-chip SAR ADC I have ever used was basically useless in its last 2 bits or so. This goes back to Hitachi microcontrollers c. 1990, and everything else I have used since. I always ended up doing say 100 conversions (SAR ADCs are very fast ) adding them up and dividing by 100, to get 10x less noise. It would be a miracle of engineering if this 12 bit ADC delivered a clean 12 bits, especially on any real PCB!

OTOH, delta-sigma ADCs can be awesome. I have an ADS1118 and a MCP3550 within an inch or two of this ARM and their noise is amazingly low. The ADS1118, on 8 convs/sec, does a clean 16 bits, and the MCP3550 does a clean 20 bits. Of course they are very slow, but in so many applications, especially accurate ones, this is fine.

[T3sl4co1l]

Very slow ADC settings have the problem that charge leaks out during the conversion, leading to errors.  This should be in the datasheet somewhere.  (I don't know exactly how this relates to this particular chip's settings.)

Another thing, which I find hard to understand why it would not apply to this ADC: every on-chip SAR ADC I have ever used was basically useless in its last 2 bits or so. This goes back to Hitachi microcontrollers c. 1990, and everything else I have used since. I always ended up doing say 100 conversions (SAR ADCs are very fast ) adding them up and dividing by 100, to get 10x less noise. It would be a miracle of engineering if this 12 bit ADC delivered a clean 12 bits, especially on any real PCB!

Surely you did 128, not 100, especially back then!

My experience with AVRs at least, has been good.  The ATmegas (at least the older of the family?) have a 10 bit ADC, which is spec'd rather poorly (more like 8 bits, without calibration), but at least tends to be stable (only quantization noise).  Their onboard reference is pitiful, more of a glorified diode junction than any kind of reference.  The XMEGAs have 12 bit ADC (and also much faster, and multichannel or pipelined depending on model), and an onboard reference that's actually worth a damn (though certainly not 12 bits of damn, you need an external ref for that of course).  I did a project recently with an ATXmega64D3 sampling at 200kS/s (8x oversampling, 25kS/s result), and found fairly stable LSBs there as well, even despite rather poor wiring (breakout board, fly wires everywhere).  Which is actually a bit annoying as I'd actually like a little noise to get some dithering!

I have more indirect experience with STM32 but from what I've seen and used, they seem to be in a similar category as the XMEGA's.  Again, give or take errata like glitches caused by CPU or other peripheral activity.

If you don't need a fast ADC, that's your own damn problem.   It doesn't hurt anything being there; at worst, you can always take a few samples and do whatever statistics on them you want, then disable the peripheral until it's time to sample again.  And even that doesn't matter, if you don't need to conserve battery power or whatever.   I suppose the only downside is, you have to reserve a timer to set that up.  But you're likely to be using one already for global timing purposes, or are likely to have extras, so it's not much of a problem most times.

OTOH, delta-sigma ADCs can be awesome. I have an ADS1118 and a MCP3550 within an inch or two of this ARM and their noise is amazingly low. The ADS1118, on 8 convs/sec, does a clean 16 bits, and the MCP3550 does a clean 20 bits. Of course they are very slow, but in so many applications, especially accurate ones, this is fine.

The downside is actually the interface.  It seems, pervasively, across all brands -- there's always some stupid gotcha with them.  It must be something like, a big mfg came to all of them (because 2nd sourcing) with the same spec, and that spec required an internal MCU to orchestrate all the functions or something, and so there's buggy software* involved, and who knows what kind of jank the bus interface (usually I2C or SPI) has?

*Well, firmware.  Or, it's probably mask ROM... rigidware?!

One particularly braindead example was an ADI part (I don't remember the number), which never stops shifting.  SPI frames aren't terminated by deasserting /CS.  Nope, if you should ever accidentally get one clock too many, or too few, you have to power cycle the miserable thing.

I think there was some odd behavior with the ADS1220?  But I wasn't involved in the software bring-up on that project, and it was a few years ago now.  I remember they got it working eventually, and the sampling variance was in the ballpark of the datasheet values (despite putting an AFE in front), so I wasn't worried, it seems I did my job.

Tim

[peter-h]

The SPI delta-sigma devices are weird in the way they signal end of conversion. They use the DOUT line, which goes to the SPI DIN. But the SPI UART can't sense the DOUT state because it is a UART (USART). You have to either use another I/O pin to watch DOUT, or unprogram the SPI interface for watching DOUT. It's stupid; they should have the EOC state accessible over SPI. The SPI clock rates are fast enough - 4MHz or so. And they could be 40MHz, like they are for the little $1 serial flash chips.

Interesting about too-slow clocks; I will check that out.

Yes, back then, 128, but today the penalty is zero, with single cycle mult/div/add/sub at 32 bits or single float

ADS1220 must be a joke. Is the mass of the electron known to 24 bits?

[peter-h]

"Very slow ADC settings have the problem that charge leaks out during the conversion, leading to errors.  This should be in the datasheet somewhere"

I found some stuff in the data sheet



It looks like they specify just about everything re the ADC at 30Mhz f-adc, so best use that, and a divisor of 480 (the max possible) gives you a 16us sampling period.

Another constraint is that the on chip temp sensor wants a 10us min sampling period, so 16us is the one to use.

[Siwastaja]

It's so stupid they didn't invest the 0.1 cents needed to internally buffer Tcpu.

You basically just can't read the CPU temperature sensor in 99% of real(time) applications requiring ADC. You usually just can't stop all other conversions for such long time. If the sensor had lower impedance to ADC, you could just sample it between everything else you sample in the application.

[aheid]

FWIW if the board is decent at least the STM32F103 and STM32F303 have in my experience quite good analog performance, down to 1LSB.

[peter-h]

I am impressed that by "real time" you mean a conversion time of much less than 16us

[Siwastaja]

Well, I suppose there is a reason why even the very cheapest $0.50 STM32F0 MCUs implement an ADC capable of doing a conversion each 1µs! 10µs sampling for the temperature sensor means you skip 10 normal samples just to read the temperature.

Inductor or motor current sensing is quite typical example where you need approximately 0.5 to 2 MSPS, and where you can not stop running this conversion cycle, not even once a minute.

[peter-h]

Out of interest, what is the CPU temp useful for?

The only reason I can think of is during R&D, for detecting misconfigured pins e.g. a pin configured as an output in error, set to 1, and connected to GND.

It can't be used for ambient sensing or CJC, because the temp rise is many degrees C.

I am using an ADC right now (ADS1118) which has a chip temp sensor and its power draw is tiny, so the self heating is negligible, and I am using it for CJC. It is mounted close to the terminal block. Actually it doesn't really work due to temperature gradients but that's another story...

[Siwastaja]

CPU temp rise may be a few degrees C but during normal operation, the difference thereof isn't that big. Subtract 5 if the CPU is running 5degC over the PCB assembly .

CPU temp is a good estimate of the PCB assembly temperature, and given a small integrated product with tight layout, it estimates the temperature of the power components quite well. Reading 80degC when it should read max 60 degC is a good indication someone put a blanket over the thing and the MOSFETs are already reaching 120 degC... An NTC placed right next to the MOSFETs would react more quickly, of course.

Generally, intergration of parts reduce costs and increase reliability.

Of course, it's never very precise, and not always useful, but sometimes it would be able to do the job. And then you can't use it unless you stop doing normal ADC conversions for a loooong time. Sucks.

[bson]

Out of interest, what is the CPU temp useful for?

The only reason I can think of is during R&D, for detecting misconfigured pins e.g. a pin configured as an output in error, set to 1, and connected to GND.

Or, after 5 years in a box somewhere whatever is connected to that pin is shorted.  It's just another sensor with a near-zero false positive rate that can signal a failure, permitting orderly shutdown before there is a more serious problem.

[peter-h]

This is interesting. The internal ADC.

We are running at 168MHz, which with a divisor of 6 gives 28MHz Fadc. That's the closest one can get to the data sheet figure of 30MHz which all the data is based on.

Then how do you keep the sampling period so you can measure both the temp sensor and keep the sampling period below the 16us max in the data sheet? DIV by 480 gives you 17.1us, and the next divisor is 144. You can't achieve anything between 10us and 16us.

What am I missing?

[aheid]

What am I missing?

Maybe I misunderstood you, but you can specify the number of (ADC) clock cycles to use for sampling on a per-channel basis, on the STM32F417 up to 480 cycles. So with a 30MHz ADC clock you can set regular channels to 3 clock cycles and the temp to 480 cycles = 16us sampling time.

[Siwastaja]

You don't need to be exactly between 10 and 16 µs. Pick the closest one which suits you better. On one end, accuracy suffers because of ADC channel crosstalk due to too high impedance of the temperature sensor; on another end, accuracy suffers due to ADC leakage. In the end, the magical numbers are just some educated guesstimates by the ST designers.

With these ST microcontrollers, you just can't be pedantic and follow all the datasheet requirements, otherwise you can't do anything with these chips.

Besides, often the given information is plainly wrong and you need to do something out-of-spec to get it even work. Just keep going.

[aheid]

Then how do you keep the sampling period so you can measure both the temp sensor and keep the sampling period below the 16us max in the data sheet?

I interpret the max sampling time in the datasheet as the maximum obtainable, due to the limited values of possible cycle counts for sampling. So it's not that you shouldn't exceed it, but rather you can't due to hardware limitations.

Similar to how the minimum and maximum output swing of an opamp is defined in the datasheet.

[peter-h]

It will be interesting to do some tests on the precision, between 3 cycles and 480 cycles. The data sheet doesn't distinguish.

With a delta-sigma ADC there is a massive difference in the noise rejection but probably not with an SAR ADC.

[aheid]

It will be interesting to do some tests on the precision, between 3 cycles and 480 cycles. The data sheet doesn't distinguish.

Well it does give you a formula (equation 1 in the datasheet) for finding the maximum allowable external resistance for the accuracy to be below 1/4 LSB. If you exceed that you will indeed find the results are affected.

edit: aaand I totally forgot about how this thread started...

[peter-h]

In case anyone finds this useful:

I've been testing the ADC, with a 100nF ceramic across the input, a stable source with a Zout of a few ohms. CPU clock 168MHz, APB2 84MHz, ADC freq 21MHz. Sampling period values:

3 - produces 8 counts of noise (so last 3 bits are noise)
15 28 56 84 112 144 480 - produces 2-3 counts of noise (so last 1-2 bits are noise)

I am running with 144 which is a sample period of 7us. For the temp sensor I would use 480 (22us and outside the ADC spec but there is no other option).

So it is really a 10-11 bit ADC.

Taking 100 readings (which takes very little time unless it is a demanding application) and averaging results brings the noise down below 1LSB.
Averaging 1000 readings brings the noise down to more or less nothing (below 0.01% of FS).
Averaging 1000 readings with a sample interval of 15 (0.7us) still produces more or less zero noise.

Accuracy is not affected by the sampling interval, apart from the unreasonable 1st one. These are voltages measured across a silicon diode, with a 2.5V reference, with four sampling intervals

3 - 0.5223 (0.14us!)
15 - 0.5227 (0.71us)
144 - 0.5229 (7us)
480 - 0.5229 (23us)

So using an out of spec 23us doesn't degrade accuracy at all.

[iMo]

To your measurement - an Si diode has got -2mV/K drift of the forward voltage..
Also with stm32 (as it has been discussed a few times here) you would hardly get the ADC noise below 2-3 LSB bits without a 4 layer pcb and a careful routing (plus careful decoupling) with none capacitor at its input..

[peter-h]

Yes, I know the -2mV. The setup was temperature stabilised for hours and the measurements were taken in rapid succession. I have a ~1ppm reference source as well but would not expect it to show anything different on the ADC noise side of things.

The PCB is 4 layer and the 100nF cap goes straight to that. The various "ground" pins are appropriately separated, too. 100nF is an overkill of course; you could never make much use of a 1msps ADC with a 100nF cap across the input I just wanted to see how much noise the ADC had. It's a 10-11 bit device; I can't see getting all 12 even with a buffer right next to the ADC input pin on the CPU.

But then few if any 1msps applications need 12 bits. Looking at the amazingly complex architecture of the ADC subsystem, it is intended for stuff like 3 phase AC inverters for motor control, engine ECUs, etc, and none of that needs anywhere near 12 bits.

[T3sl4co1l]

BTW, are you measuring the source, or the reference, at this point?

It might pay to hook up a ratiometric source, so that Vref factors out.

Tim

[peter-h]

OK; I repeated the test ratiometrically, feeding the input from around 90% (1k1/10k) of Vref (TL431A, 2.5V) and with the 100nF cap across the 10k.

3 - 2.2392V
15 - 2.2392V
28 - 2.2395V
56 - 2.2397V
84 - 2.2398V
112 - 2.2398V
144 - 2.2398V
480 - 2.2399V

I thin repeated it with a 42MHz ADC clock, which is above the 36MHz max spec. At say 56 sample period I got 2.2388V which is quite a bit down, plus there was a 0.0002V variation either side so something is not working right. Remember this is averaging 1000 readings. But at 480 I got a steady value of 2.2401V.

56 - 2.2388V
480 - 2.2401V

The tempco of the ADC gain is also low - with the reading changing from 2.2400 to 2.2397 (56 sample period) as the CPU warms up. Probably of the order of tens of ppm/degC.

[aheid]

Which board did you use for testing?

With the STM32F103 you can get less noise depending on board, but of course the chip is quite different so could be that as well.

[peter-h]

It is my own PCB; not the ST development kit anymore. That board was extremely noisy; there were long tracks all over the place, with clocks etc...

On the original Q on this thread, I can report that the ADC Zin is pretty high. I am feeding ADC2 from a 2x10k 0.01% divider (Zout=5k obviously) and the readings multiplied by 2, and calibrated for the actual Vref, are

15 - 3.2865V
56 - 3.2895V
480 - 3.2901V

The actual voltage on the top of the divider is 3.2940V so the drop is about 0.1% which would suggest a Zin of about 5Mohms on the 56 and the 480 sample period settings and about 2Mohms on the 15 setting. This Zin is presumably dynamic; the effect of charging the capacitors. Plus maybe some leakage. This is as expected but it's interesting to get a handle on it like this.

So to get the error (due to source loading) under 1 LSB you would need a source Zout of about 500 ohms. I don't know how that relates to that ST formula.

But, bear in mind this is really a "10 bit ADC" so 0.1% is in the right ballpark anyway Well, unless you are happy to average the last 1000 readings, which is what I am doing to get these values.