STM 32F4: reading CPU temperature

[peter-h]

ETH off doesn't help much - maybe a few K
Crypto runs only once a minute.

[ag123]

well, not stm32 F4, recently played with a stm32f103c8 'blue pill'.
initially I've got an analogRead() or kind of running every 100 ms, it gives me a reading of 50 deg C, room temp 30 deg C while touching it feels hardly warm.

when I changed the polling frequency to 1 second, it soon stabilized at about 39 deg C, I kind of conclude that there is some internal heating of the sensors etc, possibly made worse by frequent polling e.g. less than a second interval. capacitive coupling say to GND can produce ac currents that is possibly higher than simply resistive.

reducing the polling frequency may help

[peter-h]

Do you think polling the internal 12 bit ADCs is doing it?

I am actually not doing that, but I do have an option (currently OFF) for a power fail data save (512 bytes saved to SPI FLASH) which involves measuring the +5V rail (this is obviously before a 3.3V LDO) every 1ms. That ADC conversion is only a few microseconds.

I struggle to think of anything else, but the DS suggests this chip just draws in the region of 100mA anyway, which is 330mW+ and at the thermal resistance of 43°C/W (QFP100) is a temp rise of 14K which is about right for the chip temp relative to the temp of the PCB next to the CPU. That's reassuring; it suggests I am not doing something stupid, like cooking some GPIO MOSFET.

[ag123]

I'm just speculating:
Assuming that we 'sample' things into a capacitor and 'discharges' it, sample it again, rinse and repeat.
if we do it fast enough, and if that there are after all some non trivial circuit resistance, we are practically charging and rapidly discharging an 'RC' circuit.
the ADC probably have some small capacitance, for that sampling, but I'd think it is 'quite small', but that there could be other parasitic capacitance scattered around that adds practically a 'short circuit' to GND for an A/C current, if we do it 'often' enough. hence, those resistances that happened into fall into the pathway could practically heat up by means of that 'a/c' current.
Again this is just speculation and it could be simply nonsense.

my guess is to try to sample the same at different sampling speeds e.g. 10 ms intervals, 100 ms intervals, 1 sec intervals,  5 secs intervals etc to see if they are after all different.
if those at 10ms and 100ms gives a 'high' reading, then there could be some processes to that effect, circuits on the die heating up etc.

[peter-h]

I've just done a quick and dirty test at 84MHz instead of 168MHz. Took me about an hour because the 168MHz was de facto hard coded in e.g. the PLL config.

The CPU delta T is roughly halved. The PCB temp is about 40C, at 84MHz the chip is 49C, at 168MHz it is 58C.

The CPU now sleeps (the WFI in the RTOS idle task) about 1/2 of the time it was sleeping before, which is to be expected.

I can't actually do this because the 32F417 cannot do the 48MHz USB source at 84MHz... but I can get diagnostics via the HTTP server which amazingly all runs fine.

Anyway, this confirms the CPU power is pretty much clock related and not due to some excessive GPIO issues.

[wek]

> I can't actually do this because the 32F417 cannot do the 48MHz USB source at 84MHz...

Of course it can. You should've left the M and N of PLL as they were, generating 336MHz at the VCO, and then leaving Q=7 which outputs 336/7=48MHz to USB, just doubling P, so that it divides VCO by 4 (336/4=84) instead of 2.

JW

[ag123]

CPU speeds do matter, I've once played with a stm32 h743
https://github.com/WeActStudio/MiniSTM32H7xx
at the rated speeds 480 Mhz, the cpu literally feels hot / warm, like 50-60 deg C possibly.
when I temper sysclock to run at 1/2 speeds 240 Mhz, it practically runs at 'room temperature'

as for the clock frequencies, I've made a little python script to explore the PLL configurations, the M, N, P, Q multipliers
https://www.stm32duino.com/viewtopic.php?t=78
you may like to play with it to see if it could give some 'better' configurations

there is also another thing about power consumption: if possible, turn off clocks to as many peripherals as possible, i.e. don't clock them
e.g. switching off entire banks of gpios, and switching off pheriperials that is not in use. turn all that pins to input hi-Z if they are after all unused.
i think that can dramatically reduce power consumption. it is also one of the difficult things to troubleshoot and find where it happens.
e.g. if the chip is after all sinking currents say from a LED say like 10ma, that may create quite a bit of heat as in that small area on the die it won't be that fast or even feasible to dissipate that heat.

[peter-h]

JW - thank you.

I did a quick and dirty job because I could not find where the Systick frequency (the RTOS task switching frequency) is set. The ST code is incredibly convoluted, I found nothing obvious in the RM, and it clearly was running at 2kHz instead of 1kHz.

Probably my UARTs were buggered too but it wasn't important for this test.

If the job is done right, SystemCoreClock magically appears somewhere and everything is tied into that, with division ratios, macros, etc. I just do a #define for it

ag123 - the only spot where I know I am sinking current is five LEDs at about 3mA each. Maybe I will try the HIGH slew rate because that switches in a bigger area MOSFET. However, this is not significant. I tried GPIO_SPEED_LOW and GPIO_SPEED_HIGH. Both drop 74mV across the MOSFET (which really surprised me), and the CPU temp is the same. Maybe a 0.1K change.

I wonder what chip temp the H7 runs at... 480MHz will come at a price.

[wek]

I did a quick and dirty job because I could not find where the Systick frequency (the RTOS task switching frequency) is set.

I see.

Note, that

The ST code is incredibly convoluted

and

If the job is done right, SystemCoreClock magically appears somewhere and everything is tied into that, with division ratios, macros, etc. I just do a #define for it

are the same thing. You can't have one without the other.

You can write it yourself, though, and go as convoluted as you wish... ;-)

JW

[peter-h]

Right... although AFAICT there is no obvious simple way, at compile time, to work out e.g. the PLL integers, using just the compiler features. Some CPU frequencies will be impossible. The obvious way is to #define a number of CPU clock speeds and hard code the PLL numbers for each of those.

Had a look at the original project which was evidently code-generated using Cube MX and they squirt out the source:

Code: [Select]

  __HAL_RCC_PWR_CLK_ENABLE();
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
  /** Initializes the CPU, AHB and APB busses clocks
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 25;
  RCC_OscInitStruct.PLL.PLLN = 336;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 7;
In case someone finds this in the future, here is my code

Code: [Select]



// Hang around for delay in microseconds

__attribute__((noinline))
void hang_around_us(uint32_t delay)
{
  extern uint32_t SystemCoreClock;

  delay *= (SystemCoreClock/4100000);

  asm volatile (
    "1: subs %[delay], %[delay], #1 \n"
    "   nop \n"
    "   bne 1b \n"
    : [delay] "+l"(delay)
  );
}



// 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.
// This function should not be called in a totally tight loop if e.g. filtering multiple readings.
// Use hang_around_us(5) (a 5 us delay) after it if doing that.

uint16_t read_adc1_direct(void)
{
ADC1->SR = ~(ADC_FLAG_EOC | ADC_FLAG_OVR);
ADC1->CR2 |= (uint32_t)ADC_CR2_SWSTART;
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;
}



/*
 * 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!
 * However there is CPU type dependent code in MX_ADC1_Init() and other funcs it calls.
 *
 * 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; a fair
 * assumption) while we have an external 2.5V Vref which means the reading of the temp sensor
 * needs modifying by 2.5/3.3.
 *
 * See [url]https://www.eevblog.com/forum/microcontrollers/stm-32f4-reading-cpu-temperature/[/url]
 *
 * The function is mutexed so cannot be called before RTOS starts.
 *
 * The returned value has a fair bit of noise on it - 1K or so.
 *
 */

float read_CPU_temp (void)
{

float temp,temp1,temp2,cputemp;
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 an assumed Vref of 3.3V)
temp1 = (float) *(volatile uint16_t*) 0x1FFF7A2C;
temp2 = (float) *(volatile uint16_t*) 0x1FFF7A2E;

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. The above mutex means this can't be done before RTOS is initialised.
// This filter reduces the noise from about 1K p-p to about 0.1K.
temp=0;
for (int i=0;i<100;i++)
{
temp += (float) read_adc1_direct();
hang_around_us(5); // Delay needed - see read_adc1_direct() comments
}
temp /=100;

// Adjust for our Vref / ST cal Vref ratio.
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);

}


/**
  * @brief internal ADC1 Initialization Function
  * @param conv_interval_cycles is e.g.
  * Values allowed for the interval are 3 15 28 56 84 112 144 480
  * 56 or above produces no further noise or accuracy improvement
  * ADC_SAMPLETIME_144CYCLES for 7us  conv interval
  * ADC_SAMPLETIME_480CYCLES for 23us conv interval (required for reading on chip temp sensor)
  * @retval None
  * ADC1,ADC2 run from APB2.
  * ADC clock is already enabled in b_main.c
  * The ADC is ENABLED.
  *
  * The parameter read_vbat, if true, reads the Vbat value (channel 18). Otherwise it reads channel 8 (PB0).
  * Note that the returned value is scaled differently according to whether it is a 417/437. This uses
  * the g_dev_id value. The caller to KDE_ADC_ST_read() needs to adjust for this.
  * Note that after the ADC has been set up with read_vbat=true, and the battery is measured, it needs
  * to be set up with read_vbat=false for subsequent KDE operations.
  *
  * As above for reading CPU temperature.
  *
  * The last two params are mutually exclusive!
  *
  */

void MX_ADC1_Init(uint16_t conv_interval_cycles, bool read_vbat, bool read_temp)
{

extern uint32_t g_dev_id;

// Set up pins

GPIO_InitTypeDef GPIO_InitStruct = {0};

// ADC1 GPIO Configuration
// PB0     ------> ADC1_IN8

GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

// Configure the global features of the ADC (Clock, Resolution, Data Alignment and number of conversion)

ADC_ChannelConfTypeDef sConfig = {0};

KDE_hadc1.Instance = ADC1;
KDE_hadc1.Init.ClockPrescaler = ADC_CLOCK_SYNC_PCLK_DIV2; // 21MHz ADC clock, from APB2=42MHz
KDE_hadc1.Init.Resolution = ADC_RESOLUTION_12B;
KDE_hadc1.Init.ScanConvMode = DISABLE;
KDE_hadc1.Init.ContinuousConvMode = DISABLE;
KDE_hadc1.Init.DiscontinuousConvMode = DISABLE; // done in ADC_ST_Init anyway
KDE_hadc1.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;
KDE_hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;
KDE_hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;
KDE_hadc1.Init.NbrOfConversion = 1;
KDE_hadc1.Init.DMAContinuousRequests = DISABLE;
KDE_hadc1.Init.EOCSelection = ADC_EOC_SINGLE_CONV;
ADC_ST_Init(&KDE_hadc1);

// Configure for the selected ADC regular channel its corresponding rank in the sequencer and its sample time.

if (read_vbat)
{
sConfig.Channel = ADC_CHANNEL_18; // The DS says VBATE=1 sets ch 18 - wrong!
}
else if (read_temp)
{
if (g_dev_id==417)
{
sConfig.Channel = ADC_CHANNEL_16;
}
if (g_dev_id==437)
{
sConfig.Channel = ADC_CHANNEL_18;
}
}
else
{
sConfig.Channel = ADC_CHANNEL_8;
}

//sConfig.Channel = ADC_CHANNEL_8;
sConfig.Rank = 1;
sConfig.SamplingTime = conv_interval_cycles;
ADC_ST_ConfigChannel(&KDE_hadc1, &sConfig, read_vbat, read_temp);

// Enable the ADC
ADC1->CR2 |= 1;

// This is needed only if someone actually reads the ADC immediately after init. Actual min is about 5.
hang_around_us(20);

}


/**
 * Simplified version of HAL_ADC_ConfigChannel, just for our two ADCs.
 *
* @brief  Configures for the selected ADC regular channel its corresponding
*         rank in the sequencer and its sample time.
* @param  hadc pointer to a ADC_HandleTypeDef structure that contains
*         the configuration information for the specified ADC.
* @param  sConfig ADC configuration structure.
*
* If read_vbat=true, we set the VBATE bit in CCR, otherwise we clear it.
* If read_temp=true, we set TSVREFE
* Above two are mutually exclusive!
*
*/

static void ADC_ST_ConfigChannel(ADC_HandleTypeDef* hadc, ADC_ChannelConfTypeDef* sConfig, bool read_vbat, bool read_temp)
{

/* Clear the old sample time */
hadc->Instance->SMPR2 &= ~ADC_SMPR2(ADC_SMPR2_SMP0, sConfig->Channel);

/* Set the new sample time */
hadc->Instance->SMPR2 |= ADC_SMPR2(sConfig->SamplingTime, sConfig->Channel);

/* Clear the old SQx bits for the selected rank */
hadc->Instance->SQR3 &= ~ADC_SQR3_RK(ADC_SQR3_SQ1, sConfig->Rank);

/* Set the SQx bits for the selected rank */
hadc->Instance->SQR3 |= ADC_SQR3_RK(sConfig->Channel, sConfig->Rank);

if (read_vbat)
{
ADC->CCR |= ADC_CCR_VBATE;
}
else
{
ADC->CCR &= ~ADC_CCR_VBATE;
}

if (read_temp)
{
ADC->CCR |= ADC_CCR_TSVREFE;
}
else
{
ADC->CCR &= ~ADC_CCR_TSVREFE;
}

}



[ag123]

@peter-h
I ran my python script
https://www.stm32duino.com/viewtopic.php?t=78
and got the following

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: 4 (RCC_PLLP_DIV4) q: 8 fusb: 48.0 fcpu: 96.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
among the things, the crystal frequency is assumed to be 25 Mhz
It is good to check and confirm that as otherwise, you may be running the cpu at speeds that you do not intend it to be, e.g. heavily overclocked.

[langwadt]

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.

maybe mention already but the stm32 "Vref" is a big backwards, it isn't the Vref for the ADC it is a voltage you can measure the the ADC and from that calculate what you ADC supply (reference) is

[peter-h]

you may be running the cpu at speeds that you do not intend it to be, e.g. heavily overclocked.

Thank you for that calculation! Really handy.

Yes you are right, but only with hindsight When this project was started, maybe 5 years ago, we (myself and the Monday pm guy who originally set it up with Cube MX) had no idea how much CPU power would be needed.

Halving the clock saves around 50mA, on a total draw for the product of about 200-300mA. That could be very handy one day, and can be done with a single #define (well, plus a load of other work to check everything because if I drop PCLK1,2 from the present 42MHz I will have some work to do). Some other stuff to consider when dropping PCLK1,2 will be that my 21MHz SPI3 clock will unavoidably drop to 10.5MHz which will halve the filesystem read speed (but this is OK too). My quick and dirty test left these two at 42MHz since there is an auto calculation at built-time.

I also need 25MHz output for ETH PHY (LAN8742) and there are some complicated issues around that which are all over the internet (some say you need 50MHz but you don't, and I don't want to revisit that stuff).

I looked up the Icc of an STM32H723VGT6TR and it is literally the same as the 32F4xx per MHz. So that chip is going to run pretty hot!

the stm32 "Vref" is a big backwards, it isn't the Vref for the ADC it is a voltage you can measure the the ADC and from that calculate what you ADC supply (reference) is

Yes; to store Vref they would want to store a float

I don't use the internal Vref; a TL431 costs under 10p and is far better. The 12 bit DACs and ADCs are actually quite good then.

[peter-h]

I captured the CPU temp at 10ms intervals, starting at a few ms after power-up, for 1000 values.



The first steep slope is probably my external reference doing funny stuff. I can't see a physical explanation relating to the chip, except maybe rapid chip heating once the PLL sorts itself out and winds the clock up from 16MHz to 168MHz. Or maybe the ADC just does not work for some other reason.

The actual ambient was 26C.

So the error is about 8C. That's quite bad considering the two calibration points.

This is the whole 10 seconds. The RTOS starts up after about 300ms



Interesting exercise but I'd say my calculation is duff.

[wek]

> The actual ambient was 26C.

Ambient is what, temperature of PCB, or temperature of air somewhere in the room?

Try the same at the lowest possible clock, with no other peripherals running, while measuring temperature of the PCB.

JW

[peter-h]

PCB temperature. I let the board stabilise for say 30 mins, power off. And I have a PT100 thermometer touching the board.

Why no other peripherals running? All I am looking for is the t=0 intercept temperature.

More to the point, I don't get how ST ensure that their two cal points are at  30C and  110C. Unless they have a means of measuring the chip temp using a direct means... e.g. IR imaging.

My external Vref circuit has a time constant of about 2ms.



Digging around some other chips e.g. the 32L4xx I see this in the DS



which tells us

- the Vref for the ADC was indeed 3.0V for some chips (the 32F4 DS does not state the 3.3V quite so explicitly)
- if the 32F4 was calibrated at 3V the error I am seeing would be even bigger
- they have a 5C spec on the temperature of  30 and  110, anyway, which is most of the error I am seeing!

EDIT: the above is with a 32F417. I have another board, 32F437, which was settled at 26C for an hour and the startup temp data grab yields an even higher initial value of 38C, followed by a rising curve similar to above.

So unless there is something seriously wrong, I think the two calibration values are poorly done. IR video:

https://vimeo.com/849558390


<p>

The IR camera is over-reading by about 3C.

There are clearly two stages of heating. There is one after the power-up. There there is an LED sequence lasting ~2 secs. Then a second rise, when peripherals get initialised and the RTOS starts. One could estimate the initial time constant. I doubt the first 10ms is relevant; it's not that fast.

[ag123]

those graphs are cool, but that it seemed to suggest something is heating up

here is some graphs I did when I play with Raspberry Pi 4 with and without a heatsink
https://forums.raspberrypi.com/viewtopic.php?t=271933
https://forums.raspberrypi.com/viewtopic.php?p=1649751#p1649751

a load is being run cpuburn-a53, the climbing temperature curves is tell tale of heating going on, in my case it is deliberate the benchmark program running full throttle.
putting a heatsink is probbably overdo on a stm32, but that I'd think airflows helps and do matter.

but that some times, my stm32 registers like 39 deg, but touching it don't feel that warm after all. my guess is that it is in part on the chip or even junction where localised heating occurs

[peter-h]

I am done with this. The way this sensor is implemented is just junk.

The qfp100 is a thin package - 1.6mm; a chip of that size (roughly 4x4mm) will be no more than 0.5mm under the upper package surface. So the temperature of the package top centre will be very close to the chip temperature. That is just obvious from the geometry. If the chip was 1x1mm and with 0.5mm packaging above it, that would not be true. Simple physics / engineering. One could make really sure by sticking a tiny PT100 in the middle of the package and putting some thermal insulation on top and comparing the PT100 with the on chip "sensor". I can do this easily; this product has a PT100 interface

So it seems clear these chip temp sensors are over-reading by best part of 10C.

It doesn't matter, but one spends so many hours going around in circles. Probably because nobody has put an IR camera on it previously.

[ag123]

i think 'lousy' temperature sensor may be a thing, after all it is hard to promise that much accuracy and precision where there are probably a million other features / transistors that make the mcu work.
and for those selling pricy microprocessors e.g. intel where it could be like $100 a piece, maybe they'd bother to make sure it is accurate, as those get featured all round in those 'overclocker's forum and benchmark sites. i've quite a few stm or maybe 'clones' that reports wayward temperatures, a few literally overheats, while for some it is just a false 'too high' and some that is wacky and totally incorrect reporting temperatures well below room temperature for the same formula.

i made do with those 'false too high' readings e.g. like 39 deg C while room is 30 or below, as long as the 'finger test' didn't show any kind of overheating, I'd ignore it.

[Siwastaja]

The first steep slope is probably my external reference doing funny stuff. I can't see a physical explanation relating to the chip, except maybe rapid chip heating once the PLL sorts itself out and winds the clock up from 16MHz to 168MHz. Or maybe the ADC just does not work for some other reason.

You could look at the reference voltage with oscillosscope, scope triggered to a sync pulse out of GPIO, to verify if the reference is doing "funny stuff". I totally can see a physical explanation for rapid temperature rise, namely small thermal capacity of the die itself, and relatively poor thermal conductivity of the plastic. Although the rise stops quite rapidly so maybe it's your reference after all, I would expect a bit more rounded/gradual change around 9ms mark.

The internal temperature sensor is not designed to be precision thing, it's for protection purposes etc so 5-10degC error even after calibration is not a big deal.

[peter-h]

Sure.

I am sure the Vref is well up within a few ms. I use the same circuit all over the place. I can't play with it much since the TL431 has specific specs on the capacitance across it, for stability, and funnily enough these even depend on the TL431 package. But if Vref was coming up slowly, you would see a high spike on the initial readings, whereas we are seeing a lag.

But the ADC itself could be doing funny stuff. It has a load of capacitors which need charging up and it probably does some sort of auto-zero at power-up.

And on top of all that we have the 3.3V Vcc risetime, together with when the CPU actually comes out of reset.

The way the initial rise stops suddenly is pretty unreal. Extrapolating the curve to t=0 yields about 34.3 which with a stabilised ambient of 26 is an 8.3C error, which one also sees on the steady state reading. And one sees a broadly similar delta between the IR on the package top and the measured value.

So I think the IR image is accurate. But watch this space; I am doing the API for the PT100 etc now...

[iMo]

Frankly, why would STM calibrate the internal temp sensor against 3.0 or 3.3Vdd??
You may use the chip at various different Vdd.. 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 (there is a picture showing the setup).
Also the DS says the VREFINT is 1.21V, +/-3mV within entire temp range, with 50ppm/C max (typ 30). That is most pobably "boxed" TC, thus the real TC at specific temp could be a bit higher, but still for 2-3digits temp reading it is ok.
For temp measurement within +/- 1.5C precision (RM) the VREFINT params are almost perfect, imho.
I do not see any problem using the VREFINT for the temperature measurement unless something got totally wrong with it..

[peter-h]

What you seem to be saying is that ADC1 is not capable of measuring the on-chip temperature sensor if an external reference is used.

The main counter evidence for that is that the two calibration values, around 900 and 1200, were definitely not obtained at Vref=1.2V. They correspond to a Vref around 3.3V.

[iMo]

What you seem to be saying is that ADC1 is not capable of measuring the on-chip temperature sensor if an external reference is used.

The main counter evidence for that is that the two calibration values, around 900 and 1200, were definitely not obtained at Vref=1.2V. They correspond to a Vref around 3.3V.

Nope, I do not say that, I only do not see a reason to use an external reference while using the internal temp sensor, when all infos I see reasonably indicate you have to use the VREFINT.. 

Also I do not understand why you cannot get 900 and 1200 while using VREFINT=1.21V.
The values returned from a 12bit ADC could be in 0-4095 range with any VREF value...

[Siwastaja]

What you seem to be saying is that ADC1 is not capable of measuring the on-chip temperature sensor if an external reference is used.

Note that converting the internal temperature is slow anyway as it needs long sampling time, so enabling internal reference and changing into it just for temperature conversion purpose is not any worse. You can keep using the external reference for everything else.