Weird ADC failure STM32F091, any ideas

[Oliver Sedlacek]

We've been building a PCB with four STM32F091s on each PCB and we've built about 50 units by now (over about 3 years). I have now seen three PCBs where the ADC readings are 'bad' on two of the four micros. By 'bad' I mean conversion values are 30% ish low.

With the design having been stable for quite a while, the chances of uncovering a new bug seem slim, but chip damage seems even more unlikely. The fault also 'went away' on one of the PCBs, so more evidence that it's not damage.

The ADC reference is VDD 3.3V on all the chips, and they all run the same code.

Anyone got any thoughts?

[ONadr.1]

I would verify the voltage on the VDDA pin directly, if the package it allows.

[Oliver Sedlacek]

Done that. I've now also enabled the PVD and set it to 2.9V, so the chip thinks the VDD is above that.

[LCE]

So, did you measure the internal Vref?

That's always my sanity check for MCU ADCs, not matter what I use as an external reference, VCC or some cheap 1% voltage ref, I always check the internal ref.

I mostly use MCU ADCs for voltage monitoring (up to 8 voltages in our analog front-ends), and I always add the internal reference to the list. So also when that one is off, it counts as power failure because the external ref can't be trusted.

[Oliver Sedlacek]

See my posting 3 up from yours. The measurement of the internal Vref is NOT consistent with actual measured VDD, so answering that question would probably crack the problem

[LCE]

Okay.

In that post I see that you use CubeMX code.

I actually do the same for internal ADC, but as soon as any peripheral causes some trouble, I go through it register by register and throw out the Cube stuff.

Could you at least compare register settings between bad and good ones?

[ONadr.1]

There aren't many options here. If the voltage VDDA-VSSA is OK, then only check the sampling time of the analog channels and the frequency for the AD converter. If the value of AD conversion is not corrupted by the program, the MCU is faulty.

[Oliver Sedlacek]

I think we'll have to see if we can source replacement parts and swap them. Curse the chip shortage!

[ONadr.1]

You can write a short test program that will verify individual analog channels with different parameters.

[Oliver Sedlacek]

True of course, but no so easy on hardware where most pins are used for something.

[ONadr.1]

For measurement internal Vref or Temp channel, you can let them unassigned. Cube Mx can set them all as analog automaticaly.

[waclawek.jan]

> You can scale unknown voltages either to the internal 1.23V or to the inferred VDD.

OK and which one do you use? Does that explain the +30% in case of VREFINT and simultaneously the -30% of external sources as given in initial post?

> ADC clocking and sampling times are all set up in the CubeMX synthesised code,

I don't know how Cube/CubeMX do things - I don't use them - but please note that contrary to most other STM32 families, the 'F0 has only one single sampling time register. So, if you perform a sequence of conversions (i.e. if ADC_CHSELR contains more than one one and ADC_CFGR1.DISCEN=0), all channels in that sequence use the same sampling time.

JW

[Oliver Sedlacek]

I was using VDD and getting these 30% discrepencies. Using IntVRef the results are much better, probably within spec.

Thanks for the reminder on sampling control, having read the ADC section many times I was aware of this. Quite why I need such a long sampling time is still a mystery

[waclawek.jan]

> I was using VDD and getting these 30% discrepencies. Using IntVRef the results are much better, probably within spec.

That would indicate problem with VREF+.

Which package are you using, is it a separate VDDA/VREF+ or the common one? [EDIT] OK had a look into the datasheet, and it appears that there's no 'F091 (probably no 'F0xx) with separate VREF+ pin. Didn't know that.

Don't you filter VDDA/VREF+ using a choke or RC filter?

JW

[Oliver Sedlacek]

Good decoupling, ground and VCC plane, ferrite between analogue and digital, just basic stuff. The mystery is why we haven't seen it historically on the bulk of the boards. I'm suspicious that they are grey market chips, maybe rejects that pass superficial testing. Going from spot on to 'quite a long way off' is odd.

[raptorhal2]

Your comment about sampling time improving the result suggests that you are sampling a high resistance, possibly a resistive network. Interaction between signals in a resistive network fed by a common supply voltage can produce puzzling results. Describe your signal sources.

If you haven't done so, read AN2834 for an explanation of when longer sampling time improves accuracy.

Cheers, Hal

[Oliver Sedlacek]

My unkown signal is between1k and 10k source resistance, less than the data sheet max of 50k. The mystery is why Vref Int measurements change with sampling time as I would have thought that this is a relatively low impedance signal.

[waclawek.jan]

> ferrite between analogue and digital

Try removing/shorting it.

Results may get noisier, but the real question is, whether this removes the gross 30% error.

JW

[waclawek.jan]

> between1k and 10k source resistance

That's not exactly low, see sampling time calculation formula in DS.

> The mystery is why Vref Int measurements change with sampling time as I would have thought that this is a relatively low impedance signal.

It is a relatively high impedance signal and datasheet requires a min.4us sampling time.

JW