STM 32F4: reading CPU temperature - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 07:48:03 am
content: Yes - I did googleThis topic is not trivial, which is why so many struggle with it. I am implementingwek's proper method which usesbothcalibration points. Most attempts use just a rough slopehttp://efton.sk/STM32/STM32_VREF.pdfwhich gives this formulatemperature = 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 thiswhich 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 onlyoneADC 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 thoughCode:/** 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 t2110.0// 2nd cal temp (from data sheet)// Two calibration points, taken in the ST factory at a Vref of 3.3Vtemp1 = (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 defaultMX_ADC1_Init(ADC1_STIME_DEFAULT,false,false);ADC1_ST_Unlock();cputemp = t1 + (t2-t1) * (temp - temp1) / (temp2-temp1);return (cputemp);}

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2023, 07:58:46 am
content: Quote from: peter-h on July 26, 2023, 07:48:03 amImportant 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.)

author: hans
author_rank: Super Contributor
timestamp: July 26, 2023, 08:20:35 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: July 26, 2023, 08:51:52 am
content: 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:QuoteEd: added RM ref.

author: wek
author_rank: Frequent Contributor
timestamp: July 26, 2023, 09:51:06 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 12:00:52 pm
content: Thanks everyoneI 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 codeI get these valuesThe 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 everythingWith 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-stm32although there somebody statesEvery device has two ADC raw values taken at 30 °C and 110 °C at 3.3 V stored internallywhich confirms what I am thinking.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2023, 12:53:28 pm
content: Quote from: peter-h on July 26, 2023, 12:00:52 pmTemperature 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.

author: hans
author_rank: Super Contributor
timestamp: July 26, 2023, 12:56:33 pm
content: 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).

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 01:07:26 pm
content: 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 badI could plot a graph of the values and extrapolate backwards to get the t=0 point

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 26, 2023, 01:22:31 pm
content: The temperature sensor needs a large sampling time or you'll get wrong readings.I useADC_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:float adcCalValue30 = *(uint16_t*)0x1FFF7A2E;float adcCalValue110 = *(uint16_t*)0x1FFF7A2C;float temperature = ( (110-30) * ( Adc_value - adcCalValue30 ) / (adcCalValue110 - adcCalValue30) ) +30;

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2023, 01:25:41 pm
content: Quote from: peter-h on July 26, 2023, 01:07:26 pmThat'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.QuoteOK, 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 26, 2023, 01:28:43 pm
content: 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:// 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 03:08:23 pm
content: QuoteThat 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.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 26, 2023, 03:43:59 pm
content: Quote from: Jeroen3 on July 26, 2023, 01:28:43 pmVdda 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?

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 04:00:50 pm
content: 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.

author: eutectique
author_rank: Frequent Contributor
timestamp: July 26, 2023, 04:05:24 pm
content: I think, you should read the calibration Vref from address 0x1fff7a2a.

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 04:12:26 pm
content: 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 1497But 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.

author: eutectique
author_rank: Frequent Contributor
timestamp: July 26, 2023, 04:13:35 pm
content: BTW, Table 70 "Temperature sensot calibratio values" -- is it from STM32F405, by any chance? But your MCUs are 417 and 437, right?

author: eutectique
author_rank: Frequent Contributor
timestamp: July 26, 2023, 04:17:19 pm
content: Quote from: peter-h on July 26, 2023, 04:12:26 pmUse it in the formula asVrefADC value that corresponds to Vref.

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2023, 04:21:22 pm
content: 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 of3.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 -265CBTW 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:// 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 duffADC1->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 makesnodifference 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 posthttps://community.st.com/t5/stm32-mcu-products/stm32f427-calculating-vdd-from-vrefint-questions/td-p/277854suggests that the value obtained makes sense if the ADC is running from theinternalVref.Re the other Q - what is this for? This is a bit of a status page, on an HTTP server, on this boxOn a related topichttps://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...

author: wek
author_rank: Frequent Contributor
timestamp: July 27, 2023, 08:05:40 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 08:27:53 am
content: I won't ask how you got the x,y values

author: wek
author_rank: Frequent Contributor
timestamp: July 27, 2023, 08:32:40 am
content: Quote from: peter-h on July 27, 2023, 08:27:53 amSo 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

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 09:11:02 am
content: That's funnySo CPU ID: 260052000751383131363834 was 0x0026 and 0x0052 on the wafer?This is too - temp rise during TLS; about 2 secondsOne can just about see it on the IR camera.Pretty obviously most of the heat is from stuff other than the CPU, but what?

author: wek
author_rank: Frequent Contributor
timestamp: July 27, 2023, 09:27:00 am
content: > during TLSETH, CRYPT, buses, memories...JW

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 09:33:50 am
content: ETH off doesn't help much - maybe a few KCrypto runs only once a minute.

author: ag123
author_rank: Contributor
timestamp: July 27, 2023, 11:15:26 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 11:46:30 am
content: 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.

author: ag123
author_rank: Contributor
timestamp: July 27, 2023, 02:35:14 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 03:12:51 pm
content: 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.

author: wek
author_rank: Frequent Contributor
timestamp: July 27, 2023, 03:16:53 pm
content: > 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

author: ag123
author_rank: Contributor
timestamp: July 27, 2023, 03:28:41 pm
content: CPU speeds do matter, I've once played with a stm32 h743https://github.com/WeActStudio/MiniSTM32H7xxat 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 multipliershttps://www.stm32duino.com/viewtopic.php?t=78you may like to play with it to see if it could give some 'better' configurationsthere is also another thing about power consumption: if possible, turn off clocks to as many peripherals as possible, i.e. don't clock theme.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.

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 04:54:26 pm
content: 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 itag123 - 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.

author: wek
author_rank: Frequent Contributor
timestamp: July 27, 2023, 05:03:11 pm
content: Quote from: peter-h on July 27, 2023, 04:54:26 pmI see.Note, thatQuoteandQuoteare 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

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2023, 05:09:26 pm
content: 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:__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 codeCode:// 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 %, %, #1 \n"" nop \n"" bne 1b \n":  "+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 duffADC1->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 https://www.eevblog.com/forum/microcontrollers/stm-32f4-reading-cpu-temperature/** 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 t2110.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 defaultMX_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 pinsGPIO_InitTypeDef GPIO_InitStruct = {0};// ADC1 GPIO Configuration// PB0 ------> ADC1_IN8GPIO_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=42MHzKDE_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 anywayKDE_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 ADCADC1->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;}}

author: ag123
author_rank: Contributor
timestamp: July 27, 2023, 08:57:57 pm
content: @peter-hI ran my python scripthttps://www.stm32duino.com/viewtopic.php?t=78and got the followingCode:FHSE: 25 m: 5 n: 48 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 10 n: 96 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 15 n: 144 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 20 n: 192 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 25 n: 144 p: 2 (RCC_PLLP_DIV2) q: 3 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 25 n: 192 p: 2 (RCC_PLLP_DIV2) q: 4 fusb: 48.0 fcpu: 96.0FHSE: 25 m: 25 n: 240 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 25 n: 288 p: 2 (RCC_PLLP_DIV2) q: 6 fusb: 48.0 fcpu: 144.0FHSE: 25 m: 25 n: 288 p: 4 (RCC_PLLP_DIV4) q: 6 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 25 n: 336 p: 2 (RCC_PLLP_DIV2) q: 7 fusb: 48.0 fcpu: 168.0FHSE: 25 m: 25 n: 336 p: 4 (RCC_PLLP_DIV4) q: 7 fusb: 48.0 fcpu: 84.0FHSE: 25 m: 25 n: 384 p: 4 (RCC_PLLP_DIV4) q: 8 fusb: 48.0 fcpu: 96.0FHSE: 25 m: 25 n: 432 p: 4 (RCC_PLLP_DIV4) q: 9 fusb: 48.0 fcpu: 108.0FHSE: 25 m: 25 n: 432 p: 6 (RCC_PLLP_DIV6) q: 9 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 30 n: 288 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 35 n: 336 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 40 n: 384 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 45 n: 432 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 50 n: 288 p: 2 (RCC_PLLP_DIV2) q: 3 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 50 n: 384 p: 2 (RCC_PLLP_DIV2) q: 4 fusb: 48.0 fcpu: 96.0FHSE: 25 m: 50 n: 480 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0among the things, the crystal frequency is assumed to be 25 MhzIt 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.

author: langwadt
author_rank: Super Contributor
timestamp: July 27, 2023, 09:09:51 pm
content: Quote from: peter-h on July 26, 2023, 04:12:26 pmmaybe 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

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 06:40:27 am
content: QuoteThank you for that calculation! Really handy.Yes you are right, but only with hindsightWhen 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!QuoteYes; to store Vref they would want to store a floatI 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 02:00:02 pm
content: 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 300msInteresting exercise but I'd say my calculation is duff.

author: wek
author_rank: Frequent Contributor
timestamp: July 28, 2023, 02:12:04 pm
content: > 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

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 02:21:00 pm
content: 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 DSwhich 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.

author: ag123
author_rank: Contributor
timestamp: July 28, 2023, 06:29:16 pm
content: those graphs are cool, but that it seemed to suggest something is heating uphere is some graphs I did when I play with Raspberry Pi 4 with and without a heatsinkhttps://forums.raspberrypi.com/viewtopic.php?t=271933https://forums.raspberrypi.com/viewtopic.php?p=1649751#p1649751a 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

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 08:29:32 pm
content: 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 interfaceSo 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.

author: ag123
author_rank: Contributor
timestamp: July 29, 2023, 07:09:43 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2023, 08:24:31 am
content: Quote from: peter-h on July 28, 2023, 02:00:02 pmYou 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 08:47:51 am
content: 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...

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2023, 10:10:43 am
content: 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..

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 10:18:05 am
content: What you seem to be saying is that ADC1 is not capable of measuring the on-chip temperature sensor if anexternalreference 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.

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2023, 10:21:56 am
content: Quote from: peter-h on July 29, 2023, 10:18:05 amNope, 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...

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2023, 10:45:03 am
content: Quote from: peter-h on July 29, 2023, 10:18:05 amNote 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 10:58:40 am
content: 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 of3.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.

author: wek
author_rank: Frequent Contributor
timestamp: July 29, 2023, 11:36:38 am
content: 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.Quote from: iMo on July 29, 2023, 10:10:43 amThey 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.QuoteAs I've said above, no.QuoteCan 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.JWJW

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2023, 11:46:10 am
content: 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"..

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 12:17:30 pm
content: 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 a1.5C lowerreading.Note also that another STM32 device DS (mentioned previously) shows a5Ctolerance on the cal values, so unless the production rig for the 32F4 is much better there is a 5C factor to start with.QuoteI 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 to50Coff. 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) haveno spec at allon 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.

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2023, 01:01:37 pm
content: Thus somebody has to ask the STM how the Tempsensor actually works

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 01:09:10 pm
content: 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.

author: wek
author_rank: Frequent Contributor
timestamp: July 29, 2023, 01:40:43 pm
content: QuoteI am sure it is not. Diodes have negative temperature coefficient.QuoteThat 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.QuoteI 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.JWJW

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 01:57:06 pm
content: QuoteWell spotted

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2023, 02:00:17 pm
content: 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 at30Cand 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 posttemperature = t1 + (t2 - t1) * (TEMP*CAL/REFINT - TEMP1) / (TEMP2 - TEMP1)has to be implemented astemperature = 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)..

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 04:51:46 pm
content: No.Iknowthe Vref (it is 2.5V 1%, optionally calibrated to 0.01%) and Iknowthe 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.

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2023, 05:23:37 pm
content: Quote from: peter-h on July 29, 2023, 04:51:46 pmI 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..

author: peter-h
author_rank: Super Contributor
timestamp: July 29, 2023, 07:57:35 pm
content: See wek's posts above. The temp sensor is not related to Vrefint in any way whatsoever.

author: ag123
author_rank: Contributor
timestamp: July 30, 2023, 06:29:47 am
content: well the bandgap ref is documented herehttps://en.wikipedia.org/wiki/Bandgap_voltage_referencethis is pretty close to stm's 1.2+ v VREFINTand interestingly the same circuit is featured as a temperature sensorhttps://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensorQuotemy guess is even slight changes in doping etc could affect the physical properties of those transistors / diodeseven the Shockley diode equation has an 'n' ideality factor to 'correct' for all those imperfectionshttps://en.wikipedia.org/wiki/Shockley_diode_equationthere are also in circuit resistances which I'd guess even some tolerance variations would affect the propertiesand not least, there is possibly localized heating on the die or practically the circuit itselfhence, 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' whateveroh 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 itthere 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 30, 2023, 08:56:02 am
content: 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 heatingI 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.1pA 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.

author: wek
author_rank: Frequent Contributor
timestamp: July 30, 2023, 10:40:34 am
content: 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 anythingblowing 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 circuitrywithout blowing air, changing system frequency to 16MHz increased temperature to around 35.0deg.C (again, with time constant in low minutes)JWPS. A 'F429 Disco gives tempint around 30.0deg.C at the same 24.5deg.C ambient. I lazily used the same elf.

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: July 30, 2023, 04:07:08 pm
content: 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.

author: ag123
author_rank: Contributor
timestamp: July 30, 2023, 05:30:48 pm
content: well, i'd guess all of us may be speaking about 'different things' as in the blind men describing an elephantas for my own observations, I *vaguely* remember playing with different stm32f103c8 'blue pill' boards.https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.htmland using stm32duinohttps://www.stm32duino.com/https://github.com/rogerclarkmelbourne/Arduino_STM32https://github.com/stm32duino/Arduino_Core_STM32and codes are like suchCode:void setup() {Serial.begin();// vrefintadc_reg_map *regs = ADC1->regs;regs->CR2 |= ADC_CR2_TSVREFE; // enable VREFINT and temp sensorregs->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/Cfloat 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_STM32it 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 temperatureambient is mostly betw 28-30 deg Cif these 'casual' observations are taken 'casually', it kind of says that the temperature sensor can vary between chipsit 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 seriouslyas for 'localized' heating, a temperature gradient is often present even with heat transfer from a finhttps://web.mit.edu/16.unified/www/SPRING/propulsion/notes/node128.htmlhence:wek's findings 33.5deg.C; ambient is 24.5deg, delta T 9 deg Cpeter-h's finding 39 dec C, ambient 26 deg C, delta T 13 deg Cmy findings 39 deg C, ambient 28-30 deg C, delta T 9-11 deg Cis probably 'within range', i.e. on the die it is 'warmer' and at the surface it is 'cooler' (room temperature)F4 possibly 'runs hotter'

author: peter-h
author_rank: Super Contributor
timestamp: July 30, 2023, 09:23:51 pm
content: OK here we go.Tiny PT100 on top of the CPUIR camera PCB temp right next to CPU: 41CIR camera Top of CPU 46CPT100 sensor 47CCPU temp sensor 52CSo 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).

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 30, 2023, 09:52:48 pm
content: Quote from: peter-h on July 30, 2023, 09:23:51 pmIsn't that 5°C difference in the ballpark of an expected thermal slope anyway ?The die-reading itself, will always be higher than theexternalcase reading.

author: uer166
author_rank: Super Contributor
timestamp: July 30, 2023, 09:53:10 pm
content: 5C delta through the plastic and the cooler ambient side of the PT100 sounds about right!

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2023, 06:33:29 am
content: 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.

author: ag123
author_rank: Contributor
timestamp: July 31, 2023, 11:41:59 am
content: the temperature gradient would be there as I don't think that plastic is so perfectly conductinghttps://en.wikipedia.org/wiki/Thermal_conduction#Fourier's_lawQ = -k dT/dxQ ~ heat flux (w/m2)k ~ conductivity w/m-kdT/dx - temperature gradient k/mhttp://large.stanford.edu/courses/2010/ph240/iyer2/cmos power dissipationP = C x Vdd^2 x f x N^3where N is the number of bits switchingf ~ cpu frequencyC - capacitance (load + internal)Vdd - self explanatoryN - number of bits switchingassuming that to 'do the same stuff' so as to keep N 'constant', and that C & Vdd ~ constantso P is proportional to f - cpu frequencythen go back to that heat conductivity equationQ = -k dT/dxsince the area is 'constant', so Q is practically 'P'since k is constantif 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

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2023, 12:30:06 pm
content: jesus

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 01:21:29 pm
content: Quote from: PCB.Wiz on July 30, 2023, 09:52:48 pmNot 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 01:25:50 pm
content: Quote from: peter-h on July 31, 2023, 06:33:29 amOf 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!

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2023, 02:48:51 pm
content: QuoteThat is simply not true; there are lots of insulated TO220 devices, for example. Obviously not as good as a TO3 on one of thesehttps://www.mouser.co.uk/ProductDetail/Aavid/4003G?qs=Xb8IjHhkxj6un65euulNKg%3D%3DAnyway, 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 thisSo, 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.

author: eutectique
author_rank: Frequent Contributor
timestamp: July 31, 2023, 03:05:43 pm
content: Quote from: peter-h on July 26, 2023, 12:00:52 pmYou can. In the first lines of yourmain(), 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 thendo the rest with UART.

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2023, 03:26:59 pm
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 03:32:35 pm
content: Quote from: peter-h on July 31, 2023, 02:48:51 pmYes, 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 ratingsisthe 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 03:37:31 pm
content: Quote from: peter-h on July 31, 2023, 02:48:51 pmBravo. 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2023, 03:39:36 pm
content: 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.

author: ag123
author_rank: Contributor
timestamp: July 31, 2023, 04:33:43 pm
content: just adding another blurbI think that 'little lab' done with PT-100 by @peter-hhttps://www.eevblog.com/forum/microcontrollers/stm-32f4-reading-cpu-temperature/msg4988782/#msg4988782seem 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 chipat 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 aparthttps://en.wikipedia.org/wiki/Thermal_conduction#Fourier's_lawQ = -k dT/dxQ ~ heat flux (w/m2)k ~ conductivity w/m-kdT/dx - temperature gradient k/mit 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 zeroso for that equation to 'work' the heat flow with that temperature gradient, that heat has to 'go out' at the exit e.g. the surfaceif 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 expensivenote 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 materialthis 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 againhttps://www.stm32duino.com/viewtopic.php?t=78and got these valuesCode:FHSE: 25 m: 5 n: 48 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 10 n: 96 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 15 n: 144 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 20 n: 192 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 25 n: 144 p: 2 (RCC_PLLP_DIV2) q: 3 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 25 n: 192 p: 2 (RCC_PLLP_DIV2) q: 4 fusb: 48.0 fcpu: 96.0FHSE: 25 m: 25 n: 240 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 25 n: 288 p: 2 (RCC_PLLP_DIV2) q: 6 fusb: 48.0 fcpu: 144.0FHSE: 25 m: 25 n: 288 p: 4 (RCC_PLLP_DIV4) q: 6 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 25 n: 336 p: 2 (RCC_PLLP_DIV2) q: 7 fusb: 48.0 fcpu: 168.0FHSE: 25 m: 25 n: 336 p: 4 (RCC_PLLP_DIV4) q: 7 fusb: 48.0 fcpu: 84.0FHSE: 25 m: 25 n: 384 p: 2 (RCC_PLLP_DIV2) q: 8 fusb: 48.0 fcpu: 192.0FHSE: 25 m: 25 n: 384 p: 4 (RCC_PLLP_DIV4) q: 8 fusb: 48.0 fcpu: 96.0FHSE: 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.0FHSE: 25 m: 25 n: 432 p: 6 (RCC_PLLP_DIV6) q: 9 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 30 n: 288 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 35 n: 336 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 40 n: 384 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 45 n: 432 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0FHSE: 25 m: 50 n: 288 p: 2 (RCC_PLLP_DIV2) q: 3 fusb: 48.0 fcpu: 72.0FHSE: 25 m: 50 n: 384 p: 2 (RCC_PLLP_DIV2) q: 4 fusb: 48.0 fcpu: 96.0FHSE: 25 m: 50 n: 480 p: 2 (RCC_PLLP_DIV2) q: 5 fusb: 48.0 fcpu: 120.0

author: langwadt
author_rank: Super Contributor
timestamp: July 31, 2023, 04:42:22 pm
content: Quote from: peter-h on July 31, 2023, 02:48:51 pmthe internal voltage regulator?

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 06:52:45 pm
content: Quote from: peter-h on July 31, 2023, 03:39:36 pmI 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.

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2023, 07:07:50 pm
content: I will leave that to the experts who can knock it up in 5 mins

author: peter-h
author_rank: Super Contributor
timestamp: August 01, 2023, 09:07:09 am
content: I am not sure I can cope with the flood of volunteers keen to set this up

author: wek
author_rank: Frequent Contributor
timestamp: August 01, 2023, 09:48:25 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: August 01, 2023, 01:00:31 pm
content: 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?

author: wek
author_rank: Frequent Contributor
timestamp: August 01, 2023, 01:52:14 pm
content: Quote from: peter-h on August 01, 2023, 01:00:31 pmEverything 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).QuoteFor STM32F407, see BYPASS_REG (WLCSP90, UFBGA176, LQFP176 only).JW

author: peter-h
author_rank: Super Contributor
timestamp: August 01, 2023, 02:21:38 pm
content: 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.

author: harerod
author_rank: Frequent Contributor
timestamp: August 01, 2023, 04:08:22 pm
content: Quote from: peter-h on August 01, 2023, 02:21:38 pmWell, 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.

author: wek
author_rank: Frequent Contributor
timestamp: August 01, 2023, 04:13:42 pm
content: 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

author: Siwastaja
author_rank: Super Contributor
timestamp: August 01, 2023, 04:19:36 pm
content: Quote from: wek on August 01, 2023, 04:13:42 pmWell, 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.