STM 32F4: reading CPU temperature

[peter-h]

Yes - I did google

This topic is not trivial, which is why so many struggle with it. I am implementing wek's proper method which uses both calibration points. Most attempts use just a rough slope
http://efton.sk/STM32/STM32_VREF.pdf
which gives this formula

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

I was getting weird values, although they did vary with the device temp.

The first thing which occurred to me is whether the temp sensor is in any way linked to either Vref or VCC. Most people use the internal Vref, or (especially on packages which don't have a Vref pin) use VCC. Whereas I am using an external +2.5V 1% reference. In the DS we have just this



which makes the cryptic reference to 3.3V. The device provides two cal points, at 30C and 110C, and these read back as 926 and 1201. These are AIUI ADC readings of the temp sensor at those two temps, but at which ADC Vref?? It must be 3.3V because that is the only possibility for all packages. Yet anyone reading the sensor with a different Vref needs to scale that reading by Vref/3.3. IOW, the CAL/REFINT term can just be 2.5/3.3 because one can assume the 3.3V Vcc was accurate during manufacture.

So only one ADC reading is needed.

I am ignoring the ADC gain error, which should be very small according to the DS. FWIW, the 16 bit value at 0x1FFF7A2A is 0x05d9. I wonder if using this does anything useful because CAL is the ADC measuring the internal reference, using its 3.3V reference, but where is the internal reference (about 1.2V) used?

Does this make sense?

I am getting about +48C immediately after power-up, rising to +60C after a few mins. It seems too high; the chip is barely warm to touch. Not too much noise though

Code: [Select]


/*
 * Read CPU temperature.
 * Based on http://efton.sk/STM32/STM32_VREF.pdf
 * temperature = t1 + (t2 - t1) * (TEMP*CAL/REFINT - TEMP1) / (TEMP2 - TEMP1)
 * where t1 and t2 are the temperatures at which calibration values were taken (i.e. usually
 * t1 = 30°C and t2 = 110°C, TEMP is the ADC reading taken for our actual temperature; CAL
 * is the internal reference calibration value, REFINT is the ADC reading taken for the internal
 * voltage reference; TEMP1/TEMP2 are the temperature calibration values read out from
 * system memory (from TS_CAL1/TS_CAL2 addresses).
 * The calibration addresses happen to be the same for 32F417 and 32F437. For other chips the
 * addresses below may need to vary according to g_dev_id!
 *
 * The above formula simplifies a bit, to a single ADC reading, because the two cal values were
 * taken with a 3.3V ADC Vref (some packages don't have a Vref pin, so they had to do that) while
 * we have an external 2.5V Vref which means the reading of the temp sensor needs modifying by
 * 2.5/3.3.
 *
 */

float read_CPU_temp (void)
{

float temp,temp1,temp2,cputemp,cal;
extern float g_CPU_vref;

// Two cal temperatures
#define t1  30.0 // 1st cal temp (from data sheet)
#define t2 110.0 // 2nd cal temp (from data sheet)

// Two calibration points, taken in the ST factory at a Vref of 3.3V
temp1 = (float) *(volatile uint16_t*) 0x1FFF7A2C;
temp2 = (float) *(volatile uint16_t*) 0x1FFF7A2E;
cal   = (float) *(volatile uint16_t*) 0x1FFF7A2A;

ADC1_ST_Lock();

// Set ADC1 for CPU temp measurement and set longest sample period (25us; the DS calls for 10us)
// There is also a 417 v. 437 difference, in the channel used, etc.
MX_ADC1_Init(ADC_SAMPLETIME_480CYCLES,false,true);

// Read ADC1. Done directly, to avoid some mutex-protected function which can't be called
// from an ISR or before RTOS starts.
temp = (float) read_adc1_direct();
temp = temp * 2.5/3.3;

// Finished with ADC1, set its init back to default
MX_ADC1_Init(ADC1_STIME_DEFAULT,false,false);

ADC1_ST_Unlock();

cputemp = t1 + (t2-t1) * (temp - temp1) / (temp2-temp1);

return (cputemp);

}


[Siwastaja]

I am getting about +48C immediately after power-up, rising to +60C after a few mins. It seems too high; the chip is barely warm to touch.

Important question, what is "immediately"? 100µs? 10ms? 1 second? It would make a difference. Being integrated on the die itself, the indicated temperature would be Tj. Die is small compared to the package. If the package feels "barely warm" so maybe 30degC, having another 30degC over the RthJ-A does not sound impossible.

Now thermal mass of the die is very small so if your "immediately" means 100ms then it's possible it's already risen up to +48C. You could try to modify your code to do temperature conversion as very first thing (possibly even bypassing some init code; large amount of .data copy at the start before clock configuration with slower default RC clock could take hundreds of µs). If you could do it within less than 100µs and you still get +48degC that would suggest an error in calibration/compensation/conversion.

Also make sure you are setting the analog sampling time correctly. The temperature sensor is high impedance and needs a long conversion time. I hate this, you can't use the internal temperature sensor in an application which requires ADC conversions all the time (like current/voltage conversions in a software-controlled SMPS). A buffer would have cost $0.00001 integrated on the die. (Or maybe even a dedicated super-cheap super-slow 8-bit 1sps ADC.)

[hans]

Okay, so your calibration data is ""30C and 110C, and these read back as 926 and 1201""

dT=80C, datasheet specifies 2.5mV/C slope. So we would expected 200mV (TYP) to be between the readings. The ADC readings are presumably 12-bit and the difference is 275 LSB. So 275LSB <=> 200mV is what they are saying? Well Vref would then be: 4095/275*200mV = 2978mV.  Which does not look like a 3.3V reference..

But it could be we're looking at a +/- 10% slope error here (which would be a good reason to include calibration data), but unfortunately the datasheet only specifies TYP values. Because at 25C the sensor would output 0.76V typ, thus 772.5mV at 30C with 2.5mV/C. 926/4095*3.3V=746mV, which is also way out. But to be honest I've more trust in slopes than in offsets for an on-chip sensor, because usually absolute values are terrible on-chip (+/-20% not uncommon), but relative matching should still be possible to get somewhat OK.

[iMo]

Afaik the stm32f4 int temp sensor adc measurement is always made against the internal ref (like the "VREFINT") which is not 3V3 (and this is how it works with most mcus I met, with internal temp measurement you usually cannot set a different Vref than the VREFINT).
Also you may find in the reference manual an "offset" of the returned voltage/temperature may "vary by up to 45C from chip to chip because of the process variations".
RM0090 p.416:

Temperature (in °C) = {(VSENSE – V25) / Avg_Slope} + 25

Ed: added RM ref.

[wek]

Sounds about right in every aspect, especially given you're probably excercising lots of the internals. I have a gotcha about the internal temperature being surprisingly high.

Much depends also on heating from surrounding circuitry and board layout. Also note, that much (maybe most) of the thermal conductivity goes through the leadframe/leads/copper on PCB. The epoxy/glass compound is relatively good thermal insulator.

Humans are not very good at determining temperature by touching, "barely warm to touch" may well be in the 40+ deg.C, especially with a short touch. Do you have an infrared thermometer? Also, observe, if temperature drops when you touch the package.

Also, as been said, ST warns about the internal temperature sensor not being a precision device and being more suitable to detect temperature differences.

No, the internal reference has nothing to do with the temperature sensor.

Try it with no other software running, at a low system clock; that might be closer to ambient. Although, as I've said, it might be heated by surrounding parts, too.

JW

[peter-h]

Thanks everyone

I can't see how ST can run the ADC (to get the two cal values) at anything else than Vcc, simply because some packages have no other option. And what Vcc? Why use anything other than 3.3V since almost everybody will be using 3.3V.

But if indeed those two readings were done at some other Vref, the whole sloping line will be shifted, both absolutely up/down and in the slope. So what the hell can I do?

What is the meaning of the CAL value in this? CAL is the internal reference calibration value read out of system memory (from VREFINT_CAL). What does this mean, if not using internal Vref for anything?

The top of the chip is at +48C.  The sensor reading works out at +59C.



I can't easily do a measurement within milliseconds of power application because I would have to set up a UART; no way to do Cube debugs (SWV or anything else, or USB) until a few secs later.

The timing should be OK. I am using the slowest ADC S/H option, 25us, plus a 20us wait after ADC init (when the bit for turning on the sensor is set). I could do filtering (say 100 readings, add-up and /100, for a 10x improvement) but it would slow it down too much for some scenarios. I tried it; noise is down to about 0.3K. Noise is ~1K (200ms intervals):



In this code



I get these values



The 1326 would be > 110C but is then scaled by 2.5/3.3 as described above, to yield around +60C.

Yes this chip is fully loaded, with ETH and everything With ETH off, the temp drops about 2K. but of course the PHY is off-chip.

There is a vast number of people on the web going around in circles on this e.g.
https://electronics.stackexchange.com/questions/324321/reading-internal-temperature-sensor-stm32

although there somebody states
Every device has two ADC raw values taken at 30 °C and 110 °C at 3.3 V stored internally
which confirms what I am thinking.

[Siwastaja]

The top of the chip is at +48C.  The sensor reading works out at +59C.

Temperature difference of 11degC from Tj to Tc seems as expected, it's as close to right ballpark as it can get, so this result suggests you are doing the right thing with code. Now just put the whole thing in oven / freezer etc. and confirm you see similar difference.

Then you need to decide what is the purpose of the measurement. To shut down the CPU before it overheats, protecting from data corruption/etc.? Then you need the actual Tj, which is what you already have. To protect some external components on the same PCB, loosely thermally coupled to the CPU? Then you experimentally find the temperature difference between indicated CPU temperature and said external components, and add an offset. Or maybe you want a cheap-ass room temperature meter? Then you package the whole product in the final enclosure and experimentally find the offset between Tambient and Tcpu, but don't forget the larger thermal mass and long time to reach the equilibrium, which could be an hour with an enclosure.

[hans]

Measuring it against Vref(INT) would be sensible, since I presume that may also have CAL values. But, the CAL values read for the temperature sensor wouldn't make much sense. 926LSB @30C in 12-bit would only 274mV, whereas we expect more like 772.5mV.

So I'm guessing it is calibrated at 3.3V, and my previous calculation shows why the calibration data is provided as either slope or offset can be way out (only typ is specified).

By the way, if the ADC reads 1326LSB, wouldn't the temperature be 52.9C? That seems to match very well with a 48.4C package temperature. The die may easily be couple of deg C warmer, and these sensors are not going to be better than +/-2C. From your thermal image it also looks like the board has plenty of stuff going on that heat it up. So 50C would not be unsurprising.

I've some ESP32 sensors in my house that run Tasmota. The beta build gathers the internal sensor data as well. It's always in the 35-40C range even though my house is (fortunately) not that hot. But it would make sense if that tiny chip is doing WiFi comms all the time. It can easily consume 300mW idle and almost 1W while transmitting packets. Only a fraction of that power (e.g. 20dBm=100mW) would go into the air, the rest is all heat.
Now this STM32F4 chip is far bigger, but since you run a lot of peripherals at once, I wouldn't be surprised if it has a similar self-heat up if you were to run it on a bare board (e.g. STM32F4 discovery).

[peter-h]

Using IR, I see the chip top go from 28C to 47C (power off, settled, to power on, settled) while the sensor reading from from 44C* to 54C.

*That 44C is about 10 secs after power-up, otherwise it obviously would be 28C. Well, assuming I am calculating it right!

The purpose of this is to remotely pick up cases of badly installed units. Obviously I won't just get telemetry (customers would be a bit pissed off ) but it is an option if there is a problem, to log into the HTTP server and see the CPU temp there. If somebody put this box is a rack full of gear and it is at +100C, and the box is starting to melt, then this can be picked up. It is also a telemetry option for customers.

I also have an ADS1118 in there which has a much more accurate sensor on it (typically used for TC CJC, although in reality you have to tweak that value also unless you put a PT100 or something right inside the terminal block) but that is an optional feature, so this CPU sensor is the best I will get for free. I spent only ~5hrs doing this so it's not bad

I could plot a graph of the values and extrapolate backwards to get the t=0 point

[DavidAlfa]

The temperature sensor needs a large sampling time or you'll get wrong readings.
I use ADC_SAMPLETIME_239CYCLES_5, you're using 480 cycles so it seems more than enough.

Then the formula for STM32F07x (Which seems to be the same):

Code: [Select]

float adcCalValue30 = *(uint16_t*)0x1FFF7A2E;
float adcCalValue110 = *(uint16_t*)0x1FFF7A2C;
float temperature = ( (110-30) * ( Adc_value - adcCalValue30 ) / (adcCalValue110 - adcCalValue30) ) +30;


[Siwastaja]

Using IR, I see the chip top go from 28C to 47C (power off, settled, to power on, settled) while the sensor reading from from 44C* to 54C.

*That 44C is about 10 secs after power-up, otherwise it obviously would be 28C. Well, assuming I am calculating it right!

That's as expected, there is not much thermal inertia in the tiny die so it heats up quickly, but then there is delay through the plastic case because the plastic combines thermal resistance and thermal mass. If you want to verify my theory then add some temporary code to sample the temperature from very start (from the first hundreds of µs if at all possible) and plot it.

The purpose of this is to remotely pick up cases of badly installed units. Obviously I won't just get telemetry (customers would be a bit pissed off ) but it is an option if there is a problem, to log into the HTTP server and see the CPU temp there. If somebody put this box is a rack full of gear and it is at +100C, and the box is starting to melt, then this can be picked up. It is also a telemetry option for customers.

OK, sounds similar to what I did in the latest product, just let one run on your table for an hour or two for thermal equilibrium, record the difference between your room temperature and indicated Tcpu (any offset error here does not matter, as long as gain is roughly correct), and just subtract this difference for estimation of surrounding ambient temperature. You can just hard-code the offset somewhere, just make a note that if others change the thermal design (e.g. different case) then this needs re-evaluation. Then specify the product for some maximum ambient installation temperature e.g. +45 degC and if some unit reads +60 you can then call them about bad installation.

[Jeroen3]

Yeah, this sensor is difficult.
In order to use the calibration number for accurate temperature you need to know how much your Vdda is.
And to know Vdda you need to first measure Vrefint. But Vrefint has horrible tempco.
So to determine Vrefint you need to know the Tj.... But you don't know since your sensor isn't calibrated.

This caused me some headache as well. In the end I just accepted my losses here.

Code: [Select]

// slope and offset can be calculator from TS_CAL once
//#define v30  ((float)*TS_CAL1)
//#define v110 ((float)*TS_CAL2)
//v30 = (v30 / 4096.0f) * 3.3f;
//v110 = (v110 / 4096.0f) * 3.3f;
// slope = 80.0f / (v110-v30);
// offset = 30.0f - slope * v30;
float vx = adc_sensor / 65536.0f * vref;
float temperature = vx * slope + offset;

110 is the maximum Tj, above is a problem. You can get there very easily if you're not frugal with your io currents!

Fun fact, if you do pulsating intense FPU calculations, like with DSP, you can actually see a temperature ripple on the sensor and vdda, maybe even on your thermal camera if you have enough framerate! So yes, the F4 is a horrible part for analogs.

[peter-h]

if you're not frugal with your io currents!

That is interesting.

I am driving 5 LEDs, via 470R resistors, pulling them to GND, and with red LEDs that works out to about 2.7mA (per LED). The GPIO are PD11-PD15. They are set up for GPIO_SPEED_FREQ_MEDIUM. Only one LED is ON at any time (I am running a sequence).

Turning them off drop the chip temp about 0.5K although it is buried in the noise.

I don't think this setting is actually controlling the slew rate as is claimed; AIUI it just varies how many MOSFETs are in parallel.

The rest of the stuff I can't do anything about anyway e.g. USB 48MHz clock generation, producing a clock for a LAN8742, etc.

With all five LEDs on the CPU temp is maybe 1K higher.

The above has now been tested with both a 32F417 and 32F437 and it is exactly the same, so I am correctly dealing with the differences (which as far as is known are entirely around the Vbat and CPUtemp measurement, in how ADC1 is used to do it).

On another board, the IR image stabilises at 47C on the chip (43C on the package, off the chip) while the temp sensor stabilises at 53C. The PCB next to the chip is 41C.

At higher temps (a hair dryer) the temp difference is greater, about 9K, but that could be anything...

I see no obvious way to validate this, but it is good enough.

[DavidAlfa]

In order to use the calibration number for accurate temperature you need to know how much your Vdda is.

Vdda is normally 3.3V (Or a known fixed value, ex. 2.5V, 1.8V) with small variations of maybe 50mV caused by LDO tolerances... I don't expect the readings to drift so much?

[peter-h]

Vdda should be the supply rail which is 3.3V.

AIUI, the LDO is for the CPU, which runs at some lower voltage to get the 168MHz speed without drawing too much.

The only way to settle this is to take a reading within a few ms of power-up. I tried to capture something using the ST SWV ITM Utility, but there is no obvious way to run this without doing a build (F11) in Cube beforehand, to get a working target. Squirting some text to a UART seems the only way.

It is obviously some primitive temp sensor. I have used many silicon sensors (e.g. the DS1820) and they are nothing like as bad. But there is a lot of noise around. Not sure how one could sleep the CPU if polling the ADC; one would have to set up timer -> DMA, perhaps into a circular buffer.

[eutectique]

I think, you should read the calibration Vref from address 0x1fff7a2a.

[peter-h]

The 16 bit value at 0x1FFF7A2A is 0x05d9. Decimal 1497. What should I do with it?

It looks like an ADC conversion of the internal 1.2V Vref, with an ADC Vref of 3.3V. (1.2/3.3)*4096 = 1489. Very close to 1497 But as wek says, the internal Vref is nothing to do with the temp sensor. We just have yet another confirmation that the ADC Vref used for all this was 3.3V.

[eutectique]

BTW, Table 70 "Temperature sensot calibratio values" -- is it from STM32F405, by any chance? But your MCUs are 417 and 437, right?

[eutectique]

The 16 bit value at 0x1FFF7A2A is 0x05d9. Decimal 1497. What should I do with it?

Use it in the formula as Vref ADC value that corresponds to Vref.

[peter-h]

The 405/407, 417 and 437 all keep the two cal values in the same addresses. There are differences e.g. ch 16 versus ch 18, which I account for, having obtained the CPU version.

Sorry - I do not get what I could do with the 1497 value. That corresponds to a Vref of 1.2V. The "evidence" suggests two cal values were obtained with an ADC Vref of 3.3V. So when I read the sensor, with my Vref of 2.5V, I have to reduce the reading by 2.5/3.3.

If this was wrong in any way, I would be getting wildly off numbers. I spent a few hours, getting values like -265C

BTW on the 2nd board the two cal values are 933 and 1201. If I bodge the ADC return to 933, I get +30C as the CPU temp, which is exactly right. If I bodge it to 1201, I get +110C.

Re putting the CPU to sleep, I tried __WFI()

Code: [Select]


// Read ADC1. Done directly, to avoid some mutex-protected function which can't be called
// from an ISR or before RTOS starts.
// Output is 0-4095 corresponding to 0-Vref.
// See comments in read_vbat() below.

uint16_t read_adc1_direct(void)
{

ADC1->SR = ~(ADC_FLAG_EOC | ADC_FLAG_OVR);
ADC1->CR2 |= (uint32_t)ADC_CR2_SWSTART;
__WFI();
while (((ADC1->SR) & ADC_FLAG_EOC)==0) {} // Potential hang here but only if silicon is duff
ADC1->SR = ~(ADC_FLAG_STRT | ADC_FLAG_EOC);
return (uint16_t) ADC1->DR;

}

which should sleep the CPU until the next interrupt, which on average will not happen for quite some microseconds, and probably 1ms (RTOS tick). It makes no difference to the noise.

A google on 0x1fff7a2a is quite interesting. Usually 100 people dig around the same problem, and mostly with no solution posted. This post
https://community.st.com/t5/stm32-mcu-products/stm32f427-calculating-vdd-from-vrefint-questions/td-p/277854
suggests that the value obtained makes sense if the ADC is running from the internal Vref.

Re the other Q - what is this for? This is a bit of a status page, on an HTTP server, on this box



On a related topic
https://www.eevblog.com/forum/microcontrollers/freertos-where-should-the-cpu-be-spending-most-of-its-time/
I've been playing with how much difference the __WFI() the RTOS idle task makes. The answer is: about 5K. But it depends on what is actually running. As one would expect, code which gets the most benefit from WFI also gets the best CPU temp. But as I say the delta T is never more than 5K, hence I wonder what else is doing it. Obviously, something that runs even when the CPU sleeps...

[wek]

In attachment, readout values of VREFINT_CAL, TS1_CAL and TS2_CAL, together with their position on the wafer (they all came from the same wafer), from some 280 STM32F407.

JW

[peter-h]

I won't ask how you got the x,y values

[wek]

I won't ask

So I won't tell you that that's just what's the first 2x16 bits of the signature.

RM0090 doesn't say so, but other RMs do, and the numbers are pretty good match.

JW

[peter-h]

That's funny

So CPU ID: 260052000751383131363834 was 0x0026 and 0x0052 on the wafer?

This is too - temp rise during TLS; about 2 seconds



One can just about see it on the IR camera.

Pretty obviously most of the heat is from stuff other than the CPU, but what?

[wek]

> during TLS

ETH, CRYPT, buses, memories...

JW