STM 32F4: reading CPU temperature

[peter-h]

their plastic packages is nearly useless

That is simply not true; there are lots of insulated TO220 devices, for example. Obviously not as good as a TO3 on one of these https://www.mouser.co.uk/ProductDetail/Aavid/4003G?qs=Xb8IjHhkxj6un65euulNKg%3D%3D

Anyway, test repeated on another board and with the same delta of 5C.

Taking great care to insulate the package top (with the PT100 on it) from heat loss and thereby rendering the temperature gradient across the ~0.5mm of plastic irrelevant, I get this



So, yeah, I think the results posted earlier of > 10C were inaccurate. We are now doing better than a 5C delta.

Obviously this is OK for the job; it's just interesting.

There is also a possibility, impossible to exclude post-packaging (because it isn't possible to use the ADC within literally milliseconds of startup), that the temp sensor is sitting near some bit of the chip which heats up more than other parts.

This is a 32F417, 168MHz.

[eutectique]

I can't easily do a measurement within milliseconds of power application because I would have to set up a UART

You can. In the first lines of your main(), or even better in the start-up before initializing any hardware not related to ADC, do the minimal ADC set-up, collect measurements into a statically-allocated array, and then do the rest with UART.

[peter-h]

I did exactly that - 1000 readings, 10ms apart, push them out later, but (see above posts) didn't get a sensible result until about t +10ms.

The curve is fairly easy to extrapolate to t=0 though, although one can't be sure there isn't some local heating.

[Siwastaja]

their plastic packages is nearly useless

That is simply not true; there are lots of insulated TO220 devices, for example.

Yes, and their power ratings are more than order of magnitude worse than non-insulated counterparts, and they are specifically engineered for this purpose so use as thin plastic as possible while meeting safety requirements. Trying to heatsink through a top plastic part of NORMAL TO220, or DPAK is, as I said, nearly useless, yet some Chinese hobbyist regulator/stepper controller / etc module designers do that.

And the very reason why those plastic TO220 parts have worse power ratings is the temperature differential (Tj-Tc) which results from the plastic, proving my point! If the differential was small, they would have equally good power ratings.

Also your STM32 part is not engineered for thinnest plastic possible.

[Siwastaja]

that the temp sensor is sitting near some bit of the chip which heats up more than other parts.

Bravo. This is very well possible. And even the die itself is not infinitely good thermal conductor. The area within the temperature sensor has even less thermal mass, and even poorer coupling to the plastic than the whole die. Which is why I'm concentrating on making the point about very short thermal time constant, possibly in microsecond range more than milliseconds.

[peter-h]

OK but there is simply no way to measure it that soon. The ADC won't work then.

What I've been doing is looking for methods which come into it from different angles.

[ag123]

just adding another blurb
I think that 'little lab' done with PT-100 by @peter-h
https://www.eevblog.com/forum/microcontrollers/stm-32f4-reading-cpu-temperature/msg4988782/#msg4988782
seem to suggest that those readings are 'accurate' with a delta T of 5 deg C between the die and surface temperatures, at least for that chip
at the surface there is heat transfer by convention - i.e. air carrying the heat away.

hence, my suspicion is that blowing air at the IC or even adding a heat sink and blowing air may possibly pull the temperature gradient further apart

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

it seemed that I'm somewhat naive to simply take delta T and plug it in there, as at the surface, there is convective heat loss (air blowing at it)
in a sense this has to assume that the heat passing through that plastic is transferred out to air.

in a sense if at the surface is instead an insulator, dT/dx could practically be zero
so for that equation to 'work' the heat flow with that temperature gradient, that heat has to 'go out' at the exit e.g. the surface
if that is after all true then the surface would be assumed to be at room temperature, which is not true in 'that lab',
 i.e. the convective heat loss (air blowing at it, or rather the lack of air blowing / still air) did not remove all the heat hence it is higher than room temperature.

so the temperature gradient may be greater if a heat sink is placed with air blowing at it to remove all that heat and "real" k (conductivity w/m-k) may be smaller than if simply the die temperature is simply read (with that built-in sensor) and that pt-100. e.g. 'crappy plastic' 
well, 'high thermal conductivity encapsulating materials' are possibly expensive 

note the other scenario, if after all a heat sink + 'good' thermal compound + air blowing at it removes all the heat, and that it turns out it is 'good plastic' a high k material
this setup may pull that cpu temperature much lower which is quite similar to what all that 'overclocking' and 'cpu cooling' 'enthusiasts' are doing.
e.g. if it is 'possible' to put a heat sink + 'good' thermal compound + air blowing at it, and bring temps to room temp then run that STM32F4xx at 300 Mhz? 
ok for that sake I ran my python script again
https://www.stm32duino.com/viewtopic.php?t=78
and got these values

Code: [Select]

FHSE: 25 m: 5 n: 48 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 10 n: 96 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 15 n: 144 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 20 n: 192 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 25 n: 144 p: 2 (RCC_PLLP_DIV2) q: 3 fusb: 48.0 fcpu: 72.0
FHSE: 25 m: 25 n: 192 p: 2 (RCC_PLLP_DIV2) q: 4 fusb: 48.0 fcpu: 96.0
FHSE: 25 m: 25 n: 240 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 25 n: 288 p: 2 (RCC_PLLP_DIV2) q: 6 fusb: 48.0 fcpu: 144.0
FHSE: 25 m: 25 n: 288 p: 4 (RCC_PLLP_DIV4) q: 6 fusb: 48.0 fcpu: 72.0
FHSE: 25 m: 25 n: 336 p: 2 (RCC_PLLP_DIV2) q: 7 fusb: 48.0 fcpu: 168.0
FHSE: 25 m: 25 n: 336 p: 4 (RCC_PLLP_DIV4) q: 7 fusb: 48.0 fcpu: 84.0
FHSE: 25 m: 25 n: 384 p: 2 (RCC_PLLP_DIV2) q: 8 fusb: 48.0 fcpu: 192.0
FHSE: 25 m: 25 n: 384 p: 4 (RCC_PLLP_DIV4) q: 8 fusb: 48.0 fcpu: 96.0
FHSE: 25 m: 25 n: 432 p: 2 (RCC_PLLP_DIV2) q: 9 fusb: 48.0 fcpu: 216.0 <<
FHSE: 25 m: 25 n: 432 p: 4 (RCC_PLLP_DIV4) q: 9 fusb: 48.0 fcpu: 108.0
FHSE: 25 m: 25 n: 432 p: 6 (RCC_PLLP_DIV6) q: 9 fusb: 48.0 fcpu: 72.0
FHSE: 25 m: 30 n: 288 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 35 n: 336 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 40 n: 384 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 45 n: 432 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0
FHSE: 25 m: 50 n: 288 p: 2 (RCC_PLLP_DIV2) q: 3 fusb: 48.0 fcpu: 72.0
FHSE: 25 m: 50 n: 384 p: 2 (RCC_PLLP_DIV2) q: 4 fusb: 48.0 fcpu: 96.0
FHSE: 25 m: 50 n: 480 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0


[langwadt]

There is also a possibility, impossible to exclude post-packaging (because it isn't possible to use the ADC within literally milliseconds of startup), that the temp sensor is sitting near some bit of the chip which heats up more than other parts.

the internal voltage regulator?

[Siwastaja]

OK but there is simply no way to measure it that soon. The ADC won't work then.

I don't think ADC takes significant enough current to cause heating while not converting. Turn off all other peripherals except ADC, temperature sensor and a timer, sleep the CPU, trigger the ADC conversion from the timer, wake up when conversion finished and read the result. Consumption during sleep is not exactly zero but multiple orders of magnitude less than in fully running state.

[peter-h]

I will leave that to the experts who can knock it up in 5 mins

[peter-h]

I am not sure I can cope with the flood of volunteers keen to set this up

[wek]

Just tried my above program (attempt to low consumption/low selfheating by 2MHz sysclock and only a few seconds from powerup to read out result using debugger) on a bunch (5) of boards with 'F407/'F427 of various vintage lying around, all VDD=VDDA=VREF+=3.3V (from a bog standard LDO). Ambient is 26deg.C, results ranged from 27deg.C to 33deg.C, spread across this range regularly.

JW

[peter-h]

Is the internal regulator passing the CPU current, or CPU+peripherals?

I haven't read up on this (it seems complicated) but IIRC one can implement it externally somehow, no?

[wek]

Is the internal regulator passing the CPU current, or CPU+peripherals?

Everything except what's powered by VDDA and VBAT, and except the pin-connected part of GPIOs and the power management itself (i.e. the regulators, reset, and whatnot).

I haven't read up on this (it seems complicated) but IIRC one can implement it externally somehow, no?

For STM32F407, see BYPASS_REG (WLCSP90, UFBGA176, LQFP176 only).

JW

[peter-h]

Thanks; not applicable to my QFP-100.

AN4488 states the chip runs from 1.8V which means 46% of the power dissipation of a 32F4 is just the linear regulator, which is pretty amazing.

[harerod]

Thanks; not applicable to my QFP-100.

AN4488 states the chip runs from 1.8V which means 46% of the power dissipation of a 32F4 is just the linear regulator, which is pretty amazing.

Well, moving charges into and out of FF-cells means current. Even if that current happens at core voltage, the LDO would have to dissipate power proportionial to the voltage drop. Which gives us an interesting clue for lower power applications: use an external buck regulator. This could be as simple as a MOSFET, a diode and an inductivity. The MOSFET being toggled by a spare MCU pin.

[wek]

Some newer STM32 come with built-in buck regulator (requires external inductor). They also come with a confusing numbering: they feature a P or Q suffix, in some (most? all?) cases with a slightly different pinout than a non-suffixed but otherwise identically marked part...

JW

[Siwastaja]

Some newer STM32 come with built-in buck regulator (requires external inductor). They also come with a confusing numbering: they feature a P or Q suffix, in some (most? all?) cases with a slightly different pinout than a non-suffixed but otherwise identically marked part...

Well, at least they have different part number so nothing to complain about - one always needs to do perfect 1:1 match for the part number. ST has tradition to sell non-binary compatible, functionally non-equivalent parts under exact same part number which is a total disaster for production because you can't control which revision you buy from distributors. e.g. the STM32H743 ADC clock divider saga.