solved: rerunning STM32 ADC calibration during wild temperature swings running

[incf]

I've got a system where a STM32 MCU experiences 50C temperature swings. It only runs ADC calibration once a boot up when the system is room temperature.

Once the system's temperature has warmed up the ADC output becomes "odd" looking when swung across the full range.

It is as if there was a temperature dependent offset voltage on the lower 4 bits of the 12 bit output from the ADC. The result is a signal that jumps in a nonlinear fashion - all of the bits being compressed together and then large dead bands between.

I am looking to calibrate my ADC once per second while the system (a SMPS) is running.

Are there any gotchas to look out for when rerunning the internal STM32 ADC calibration?

edit image for newcomers:

[mtwieg]

I've got a system where a STM32 MCU experiences 50C temperature swings. It only runs ADC calibration once a boot up when the system is room temperature.

Tell us the part number, and describe how the ADC is configured (and what its trigger source is).

Once the system's temperature has warmed up the ADC output becomes "odd" looking when swung across the full range.

It is as if there was a temperature dependent offset voltage on the lower 4 bits of the 12 bit output from the ADC. The result is a signal that jumps in a nonlinear fashion - all of the bits being compressed together and then large dead bands between.

Hard to imagine exactly what this looks like (are there missing codes or is this just horrible DNL?) but it sounds like an extremely odd issue. How are you testing this? Could also be related to surrounding hardware (improper ADC input driver, poor reference/supply decoupling, etc).

I am looking to calibrate my ADC once per second while the system (a SMPS) is running.

Are there any gotchas to look out for when rerunning the internal STM32 ADC calibration?

AFAIK the self-cal only calibrates offset (not gain or linearity). I doubt it's going to help with this issue.

[incf]

Tell us the part number, and describe how the ADC is configured (and what its trigger source is).

Software triggered, running as fast as possible. It samples/accumulates for a second, then it computes averages, and does some really slow math using the averages.

• STM32C011
• ADC clock rate of around 10MHz
• sampling period of 160.5 clock cycles
• 12 bits (no hardware oversampling, all software oversampling)
• 3.3V
• roughly 10ksamples/sec
• with an input impedance of roughly 50kΩ (high input impedance might be to blame)
• at roughly the max rated operating temperature of the IC (Thermal gradient might be to blame)
• power supply and ADC channel with heavy passive filtering

I made a related post yesterday that touches on some of this as well
[1] https://www.eevblog.com/forum/projects/do-adc-total-unadjusted-error-specs-apply-at-50k-or-at-0-or-both-temperature/

AFAIK the self-cal only calibrates offset (not gain or linearity). I doubt it's going to help with this issue.

I fear that you are probably correct.

Hard to imagine exactly what this looks like

32 LSB Stairsteps in the ADC measurement of a slowly rising voltage that only develop when the board is hot. I can't show the data unfortunately.

MCU power supply is (seems to be) solid. 125C rated linear supply outputting a few milliamps - has filtering. Measurement is part of a stress test. I'm intentionally running the product (a SMPS that is monitored by this MCU) into a load at it's max output - it runs very hot. The die temperature is 70C.

All of the codes are there, it's just that it is highly nonlinear in a periodic fashion every 32 counts.

[mtwieg]

ADC clock rate of around 10MHz
sampling period of 160.5 clock cycles

Keep in mind most of the specs in the datasheet assume the ADC is clocked at 35MHz. I would try that and see if it has an effect.

with an input impedance of roughly 50kΩ (high input impedance might be to blame)

That's certainly also something worth checking. Though I would not expect that to result in the sort of behavior you're observing.

32 LSB Stairsteps in the ADC measurement of a slowly rising voltage that only develop when the board is hot. I can't show the data unfortunately.

So the lowest five bits are totally static? If so it sounds like the conversion isn't actually completing...

And this only happens above some temperature? Does it recover if the temperature is reduced again (without power cycling or resetting)?

All of the codes are there, it's just that it is highly nonlinear in a periodic fashion every 32 counts.

This contradicts what you said above.

[incf]

See hand sketch - maybe I can show it better than I can describe it.



It's a 12 bit reading. It's definitely completing. Most of lowest 5 bits "appear to be" compressed into the first 33% of a 32LSB period.

--

In another thread it was suggested that I might have a temperature gradient across my MCU's die, and it might be affecting the ADC.

And this only happens above some temperature? Does it recover if the temperature is reduced again (without power cycling or resetting)?

Only happens when the system has been hot for an hour. The system generates it's own heat. It recovers within 15 minutes of the system running at reduced power (after the MCU temperature drops).

[AndyC_772]

That's interesting. Mind if I ask which STM32 you're using? They do have a number of different ADC blocks that they use in different parts, some of which require calibration (and *really* need it!), and others of which don't.

[incf]

STM32C011 family
cheap and small
they cost 30 cents in volume and often have 20 pins or less

I don't know which ADC IP they use in this family.

I think these devices use a smaller process node than older ST MCUs.

[UnijunctionTransistor]

When I have had ADC issues in the past, what I have done is to kludge an external reference voltage, known to be stable, and run a test firmware reading the results. You may want to kludge a buffer to determine whether the relatively high source resistance is causing an anomaly.
Speaking of which, have you consulted the datasheet’s Table 54?

[incf]

When I have had ADC issues in the past, what I have done is to kludge an external reference voltage, known to be stable, and run a test firmware reading the results. You may want to kludge a buffer to determine whether the relatively high source resistance is causing an anomaly.
Speaking of which, have you consulted the datasheet’s Table 54?

A stable high precision push-pull output voltage reference is part of the product. (Which maybe is why I'm not detecting changes in absolute accuracy? just changes in effective resolution)

Yes we "seem to" be respecting the published specs (I've got a dedicated thread on that running concurrently on that specific table if you are interested https://www.eevblog.com/forum/projects/do-adc-total-unadjusted-error-specs-apply-at-50k-or-at-0-or-both-temperature/)

[UnijunctionTransistor]

Yes, I did read the data sheet and am aware that the includes an internal reference with a calibration constant.

But the thing you would be interested in finding out with my proposed experiment with an external reference voltage, is whether the internal reference or something else in the uP’s conversion chain is acting up.
And I know, I know, it shouldn’t, but…

My personal assumption whenever I am stuck in a rut, is not to assume that something could NOT be causing the issue. 

[incf]

Yes, I did read the data sheet and am aware that the includes an internal reference with a calibration constant.

But the thing you would be interested in finding out with my proposed experiment with an external reference voltage, is whether the internal reference or something else in the uP’s conversion chain is acting up.
And I know, I know, it shouldn’t, but…

My personal assumption whenever I am stuck in a rut, is not to assume that something could NOT be causing the issue.

I meant we use an external voltage reference chip on the circuit board (ST's internal voltage reference is lousy). I'll have to make sure to capture the raw ADC values for that channel in future tests.

[bson]

Doesn't the MCU have an onboard thermal sensor?  The behavior is probably reproducible, so can be solved with thermal compensation (and factory calibration).  Often the terminal sensor (or divider) is connected to an internal ADC input, for this exact reason.