STM 32F4: reading CPU temperature

[peter-h]

I agree; I am using ext Vref only because I already have it.

But I still do not get the proposition here. The DS makes it as clear as it can that the two temp cal values were obtained at a Vref of 3.3V. They also do not make sense for a Vref of 1.2V.

So if you measured the temp sensor using the internal Vref, you would make a correction of 1.2/3.3 when you read it. The 1.2 could be corrected using the internally stored Vrefint correction value. But this is identical to using a 2.5V external Vref and correcting by 2.5/3.3. After all, the 3.3 was set accurately at the ST factory (within 10mV according to another chip DS) and having this inaccurate would anyway be totally dumb in production. And my 2.5V is calibrated during my factory test, to 2.5V 0.01%, and I am using this calibrated 2.5V.

The more basic thing is that if you do this any other way, the chip temp comes out at something crazy.

[wek]

Let's make one thing absolutely clear: in STM32, ADC (and DAC) reference is ALWAYS the VREF+ pad, NEVER the internal VREFINT reference.

In smaller packages (generally below 100 pins), VREF+ is internally tied to VDDA to spare pins.

In newer STM32, there is an option to output a buffered/amplified version of VREFINT onto VREF+ pad, if it is not tied to VDDA; the module which does this is called VREFBUF. Not present in STM32F4xx.

Frankly, why would STM calibrate the internal temp sensor against 3.0 or 3.3Vdd??

They use one single power supply for VDDA and VREF+ even in packages where these pads are split to two pins, as it would make little sense to separate characterization for different packages.

While staring into the RM my impression is they say/show the temp sensor has to be read by a specific ADC channel while the reference used is the VINTREF

As I've said above, no.

(there is a picture showing the setup)

Can you please tell, which picture in which document.

---
I believe the calibration is good to a couple of deg.C, IMO less than 8deg.C. I never checked that, but I see no reason why wouldn't that be so.

Also, the TL431AI (as specificed in the drawing above) has a DS initial precision +-1%, min.2470mV, typ. 2495mV, max. 2520mV. If the specimen Peter used in the experiment is one at the lower end of the range, given that the temperature sensor's voltage is around 760mV i.e. around 1/3 of the reference, the cca 25mV reference error translates to cca 8mV error on the measurement i.e. cca 3.5deg.C. That does not explain the whole 8deg.C error, but maybe something to chew on, too.

JW

JW

[iMo]

Btw my calc below shows the closest readings to "900 and 1200" with VREF=2.56V (the V25 voltage and slope off the DataSheet, assuming 12bit ADC).

The setup picture below from "Reference Manual 0090" rev19, p.413, chapter "13.10 Temperature sensor"..

[peter-h]

My actual cal values are 926 and 1201.

The actual vref is 2.4845V (this particular board, 32F437, is uncalibrated so I was using 2.5000) and dropping that into the code yields a 1.5C lower reading.

Note also that another STM32 device DS (mentioned previously) shows a 5C tolerance on the cal values, so unless the production rig for the 32F4 is much better there is a 5C factor to start with.

my calc below shows the closest readings to "900 and 1200" with VREF=2.56V

I don't think this means anything because I've read on the internet (so it must be true) that the actual sensor output can be anything up to 50C off. The two correction points are supposed to take care of this. The following two key parameters, which is what most people posting code on the www are using (they are not using the 2 point cal method) have no spec at all on them

]

Actually, I wonder if the "sensor" is just a diode, fed with a crude constant current source? Looks about right, for a very small PN junction, driven a bit past the knee.

[iMo]

Thus somebody has to ask the STM how the Tempsensor actually works 

[peter-h]

I don't get this. If the cal values were done at 1.2 or 2.5V I get a totally silly temp; +148C using 2.5V. A 3.0V I get +121C.

I suspect you have the wrong formula for working this out.

I am sure it is just a diode, and diodes are horribly inaccurate. Especially if fed with a current source which could vary by a factor of 2 which is exactly what a diode on a "digital" chip would be like. It will be a nasty shitty diode.

[wek]

I am sure it is just a diode,

I am sure it is not. Diodes have negative temperature coefficient.

The setup picture below from "Reference Manual 0090" rev19, p.413, chapter "13.10 Temperature sensor"..

That picture says, in not the clearest way, that temperature sensor is connected to CH16/18 of ADC and VREFINT to CH17, both through a switch controlled by TSVREFE.

ADC channels still go though ADC's input multiplexer, i.e. those channels cannot be converted simultaneously; and the picture does not indicate in any way that VREFINT would be used as ADC reference.

Btw my calc below shows the closest readings to "900 and 1200" with VREF=2.56V (the V25 voltage and slope off the DataSheet, assuming 12bit ADC).

I wonder how did you calculate that. From 760mV @ 25deg.C and 2.5mV/deg.C slope, at 30deg. (temperature where TS_CAL1 was taken) I have 760+5*2.5=772.5mV, and if TS_CAL1 is given as 926, that corresponds to 772.5mV*4096/926=3417mV which is within reasonable error from 3.3V given by DS for TS_CAL1.

JW



JW

[peter-h]

Diodes have negative temperature coefficient.

 

Well spotted

[iMo]

It seems the VREF_INT has to be measured via the ADC and then used for the calculation of the actual VREF_EXT (as the VREF_INT is not used as the reference voltage for the ADC directly).

There is the VREF_CAL stored at 0x1FFF 7A2A - 0x1FFF 7A2B, taken at 30C and at Vdda=3.3V==VREF_AT_FACTORY (table 73 of the DS)

Based on that you may calculate your actual "Vref_ext" or Vdda value (now used as the Vref for your ADC), and based on the result you may calculate the temperature..

PS: thus your formula in the first post

temperature = t1 + (t2 - t1) * (TEMP*CAL/REFINT - TEMP1) / (TEMP2 - TEMP1)

has to be implemented as

temperature = 30 + (110 - 30) * (ADC_TEMP*VREF_CAL/ADC_VREF_INT - TEMP_CAL_30) / (TEMP_CAL_110 - TEMP_CAL_30)

Thus the math does not include any special external reference, and the temperature is indeed measured against the VREF_INT (indirectly)..

[peter-h]

No.

I know the Vref (it is 2.5V 1%, optionally calibrated to 0.01%) and I know the Vref used by ST to establish the two cal values (30C and 110C, +/- 5C) and it was 3.3V +/- 10mV.

The internal Vref and any cal data for it is irrelevant.

[iMo]

No.

I know the Vref (it is 2.5V 1%, optionally calibrated to 0.01%) and I know the Vref used by ST to establish the two cal values (30C and 110C, +/- 5C) and it was 3.3V +/- 10mV.

The internal Vref and any cal data for it is irrelevant.

I would not underestimate the cognitive capabilities of the EEs in STM. They would not design an internal temperature measurement based on your assumptions..

The VREF_INT is a ratiometric source, imho, basically a voltage divider wired between Vdda and Gnd, perhaps buffered, calibrated to a specific "ratio" at 30C (the applied Vdda voltage regardless, btw).

It could be your ext "Vref" is around the 2.5V (because perhaps you have measured the VREF_INT and read the VREF_CAL and made the math) at a specific Vadd, but with a different chip it could be a different value.

PS: ratiometric - thus for "any Vdda" you get/read a VREF_INT such a constant temperature will return the same value (after the math above)..
No need to have any external reference..

[peter-h]

See wek's posts above. The temp sensor is not related to Vrefint in any way whatsoever.

[ag123]

well the bandgap ref is documented here
https://en.wikipedia.org/wiki/Bandgap_voltage_reference
this is pretty close to stm's 1.2+ v VREFINT

and interestingly the same circuit is featured as a temperature sensor 
https://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor

If high precision is not required it is enough to bias a diode with any constant low current and use its −2 mV/˚C thermal coefficient for temperature calculation, however this requires calibration for each diode type. This method is common in monolithic temperature sensors.

my guess is even slight changes in doping etc could affect the physical properties of those transistors / diodes
even the Shockley diode equation has an 'n' ideality factor to 'correct' for all those imperfections
https://en.wikipedia.org/wiki/Shockley_diode_equation
there are also in circuit resistances which I'd guess even some tolerance variations would affect the properties

and not least, there is possibly localized heating on the die or practically the circuit itself
hence, my guess is I'd take the measured temperature more as a 'guide' than any high precision / accuracy measurement.
if it measures hot, but touching the chip don't feel a difference from room temperature, i'd ignore it.

i tend to use the largest ADC sample time available, but normally, that didn't make much difference to 'accuracy' / 'precision' whatever

oh then there is the ADC itself, I tend to assume it 'is correct', as the only alternative is to use some precision voltage source to calibrate it
there is a notion that the 'steps' are 'non-linear'? well, i'd guess errors exists 
, but there is some implications given that mostly mcus are simply patched everywhere and the adc read for value as is.

[peter-h]

It is an interesting idea whether the temp sensor sits next to say the crypto area, and if you are doing a lot of AES256 you get local heating I am not sure about this producing a 10C delta though, because I can see the chip in IR, plus TLS (activity lasting about 2-3s) heats up the sensor about 1.5C.

Yes lots of people use a diode for temp measurement. It is commonly uses for CJC, where a calibration at a single point is good enough. You glue the diode inside the terminal block. 1N4148 at 0.1p

A bandgap ref is not supposed to have such a large TC, so if they use that they must have tweaked it. Yes; 1.2V is a common voltage achievable with a particular P/N junction configuration.

[wek]

The attached code runs at STM32F407 (on a 'F407 Disco, but only the LED blinking and the particular measured VREF+ (as #define VREFPLUS) are specific to that board).

It deliberately runs at 2MHz system clock (HSI / 8 ), which means 1MHz ADC clock (minimum is 600kHz). Both using manually measured VREF+ (here attached to VDDA, from a nominally 3.0V LDO, measured as 2.91V, see #define VREFPLUS) and indirectly measured VREF+ using VREFINT (see #define USE_VREFINT) implemented; unsurprisingly, results were not that different.

Output is in variable tempint read out by debugger ('F407 DISCO does not have the virtual COM - even the new ones would need to wire it up, but I have the old model anyway).

Findings:

• after inital setup, trying to have the board connected to as short time as possible until program runs, to minimize any heating, it displays around 33.5deg.C; ambient is 24.5deg.C. This is strikingly similar to Peter's findings.
• using sleep did not change anything
• blowing air at the board did decrease the temperature by about 1.5-2deg.C (time constant is in low minutes) - note that this cools not only the STM32, but also the surrounding circuitry
• without blowing air, changing system frequency to 16MHz increased temperature to around 35.0deg.C (again, with time constant in low minutes)

JW

PS. A 'F429 Disco gives tempint around 30.0deg.C at the same 24.5deg.C ambient. I lazily used the same elf.

[I wanted a rude username]

Hit a similar problem with some STM32G0s. On the Nucleo board the temperature was believable, but on the custom PCB it consistently read about 7 °C high. No code change. Main difference was the Nucleo had a QFP-64 while the PCB used a QFN-48 ... it's possible the QFP had a proper lead frame and dissipated the heat better (but on the other hand, the QFN had a full ground pad) ... or it could have just been random process variation. The STM32G series is made with a smaller process so you could expect the localised heating issue to be more severe.

The PCB had an accelerometer so I just read the temperature from that, and it was super accurate ... also meant I could remove the ADC code, which saved program memory size and simplified scheduling.

[ag123]

well, i'd guess all of us may be speaking about 'different things' as in the blind men describing an elephant 
as for my own observations, I *vaguely* remember playing with different stm32f103c8 'blue pill' boards.
https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html

and using stm32duino
https://www.stm32duino.com/
https://github.com/rogerclarkmelbourne/Arduino_STM32
https://github.com/stm32duino/Arduino_Core_STM32

and codes are like such

Code: [Select]

void setup() {
  Serial.begin();
  // vrefint
  adc_reg_map *regs = ADC1->regs;
  regs->CR2 |= ADC_CR2_TSVREFE;    // enable VREFINT and temp sensor
  regs->SMPR1 = ADC_SMPR1_SMP17;  // sample rate for VREFINT ADC channel
}

void loop() {

  uint16_t vrefint = adc_read(ADC1, 17);
  Serial.print(F("Vref int (1.2v):"));
  Serial.print(vrefint);
  Serial.println();

  uint16_t vtemp = adc_read(ADC1, 16);
  Serial.print(F("temp sensor:"));
  Serial.print(vtemp);
  Serial.println();

  uint16_t mv = (1200 * vtemp) / vrefint;
  Serial.print(F("mvolt:"));
  Serial.print(mv);
  Serial.println();

  // specs 5.3.19 temp sensor characteristics
  // V 25 deg ~ 1.43v
  // slope 4.3 mv/C
  float temp = (mv - 1430) * 1.0 / 4.3 + 25.0;
  Serial.print(F("temp:"));
  Serial.print(temp);
  Serial.println();

  delay(1000);
}
^ note based on this core: https://github.com/rogerclarkmelbourne/Arduino_STM32
it is part of my 'blinky sketch' to blink a led, and 'do something', just to show that 'it is alive' 

the codes are run on different 'blue pill' (and maple mini) boards including some with 'clones' chips - not from ST.
it turns out in my different 'batch' of boards I bought from 'online flea market' AliX, I get varied behaviors:

- I've got chip that literally overheat, the finger test say ouch and the temperature reads high > 40 deg C
- I've got chip that are 'well behaved', conform to spec and (not really overheating)
- I've got chip that 'reads high' actually not really like 39 deg C, but the finger test seem to say it is alright, 'nothing is happening' room temperature
- and I've got a chip that when I run it at 100 ms, I get 59 deg C, if I reduce the polling interval i.e. delay(1000) // 1 sec delay in loop()
that becomes 39 deg C
- and I've got chip that calc into a 'wacky wrong temperature' low below room temperature

ambient is mostly betw 28-30 deg C

if these 'casual' observations are taken 'casually', it kind of says that the temperature sensor can vary between chips
it is kind of 'bad' that it makes one wonder if some of the boards could be made with chips that are after all rejects, psst after all it is "online flea markets", or maybe we shouldn't take those temperatures too seriously 

as for 'localized' heating, a temperature gradient is often present even with heat transfer from a fin
https://web.mit.edu/16.unified/www/SPRING/propulsion/notes/node128.html

hence:
wek's findings 33.5deg.C; ambient is 24.5deg, delta T 9 deg C
peter-h's finding 39 dec C, ambient 26 deg C, delta T 13 deg C
my findings 39 deg C, ambient 28-30 deg C, delta T 9-11 deg C
is probably 'within range', i.e. on the die it is 'warmer' and at the surface it is 'cooler' (room temperature)
F4 possibly 'runs hotter'

[peter-h]

OK here we go.

Tiny PT100 on top of the CPU



IR camera PCB temp right next to CPU: 41C
IR camera Top of CPU 46C
PT100 sensor 47C
CPU temp sensor 52C

So assuming the PT100 is about right on reading the chip temp, I am seeing a delta of 5C.

Note that placing the PT100 on the CPU package does not visibly change any of the other temperatures.

The PT100 reading circuit is calibrated with a 100R 0.005% resistor and the PT100 itself is accurate to about 0.2C (Class A or B - can't remember).

[PCB.Wiz]

OK here we go.
Tiny PT100 on top of the CPU
IR camera PCB temp right next to CPU: 41C
IR camera Top of CPU 46C
PT100 sensor 47C
CPU temp sensor 52C

So assuming the PT100 is about right on reading the chip temp, I am seeing a delta of 5C.

Isn't that 5°C difference in the ballpark of an expected thermal slope anyway ?
The die-reading itself, will always be higher than the external case reading.

[uer166]

5C delta through the plastic and the cooler ambient side of the PT100 sounds about right!

[peter-h]

I don't honestly think the top of the package is much cooler than the chip, for reasons posted above (plastic very thin, heat flow geometry, IR image showing very little heat going sideways, etc).

So a 5C delta in this case, 32F437, 168MHz, 100 ADC readings averaged.

I have seen greater deviations in other setups; will do tests on those later.

[ag123]

the temperature gradient would be there as I don't think that plastic is so perfectly conducting
https://en.wikipedia.org/wiki/Thermal_conduction#Fourier's_law

Q = -k dT/dx

Q ~ heat flux (w/m2)
k ~ conductivity w/m-k
dT/dx - temperature gradient k/m

http://large.stanford.edu/courses/2010/ph240/iyer2/
cmos power dissipation
P = C x Vdd^2 x f x N^3
where N is the number of bits switching
f ~ cpu frequency
C - capacitance (load + internal)
Vdd - self explanatory
N - number of bits switching

assuming that to 'do the same stuff' so as to keep N 'constant', and that C & Vdd ~ constant
so P is proportional to f - cpu frequency
then go back to that heat conductivity equation

Q = -k dT/dx

since the area is 'constant', so Q is practically 'P'
since k is constant

if you run the cpu at different frequency hence changing P (cmos power dissipation), you would probably observe a  similar temperature gradient (proportionally smaller e.g. run at 1/2 speed, delta T is halved).
'real world' is more complicated than this, but that if it turns out to be close to that, then you can practically work out k the conductivity of that plastic, and to create more heat do some calcs as that one is N^3 

[peter-h]

jesus

[Siwastaja]

The die-reading itself, will always be higher than the external case reading.

Not if low-power modes are used, and temperature is sensed right after wakeup, or the wakeup time is short enough compared to the thermal time constant of the die (could be in milliseconds). That's really the only way to evaluate the accuracy of the internal temperature sensor itself and remove the self-heating of the chip from equation. But as peter-h isn't doing that, you are of course right.

[Siwastaja]

I don't honestly think the top of the package is much cooler than the chip, for reasons posted above (plastic very thin, heat flow geometry, IR image showing very little heat going sideways, etc).

Of course it is. At some 0.2 W/(mK), plastic is poor thermal conductor, and such IC package definitely is not "very thin". 0.1mm could be called "very thin". From power electronics we know very well that trying to cool semiconductors through their plastic packages is nearly useless; you get only a few watts out of a device which otherwise could do tens of watts. Now this MCU isn't dissipating "a few watts" but less, but you also are not seeing temperature gradients like 50degC as seen when trying to cool power packages through their plastic cases.

From experience I would ballpark 5-15degC difference over the plastic is completely as expected. But your measurements mix up two things, temperature difference between Tj-Tc and actual sensor error, and there is absolutely no way of separating them from each other unless you do what I suggest, minimize (Tj-Tc) by measuring right after (tens of microseconds) wakeup. You think (Tj-Tc) is close to zero and the sensor error is +5, but it could be that (Tj-Tc) is 10 degrees and the sensor error is actually -5!