Teensy 4.0 Internal Temperature measurement

Status
Not open for further replies.
Code:
FLASHMEM void tempmon_init(void)
{
  // Notes:
  //    TEMPMON_TEMPSENSE0 &= ~0x2U;  Stops temp monitoring
  //    TEMPMON_TEMPSENSE0 |= 0x1U;   Powers down temp monitoring 
  uint32_t calibrationData;
  uint32_t roomCount;
  uint32_t tempCodeVal;
      
  //first power on the temperature sensor - no register change
  TEMPMON_TEMPSENSE0 &= ~0x1U;

  //set monitoring frequency - no register change
  TEMPMON_TEMPSENSE1 = (((uint32_t)(((uint32_t)(frequency)) << 0U)) & 0xFFFFU);
  
  //read calibration data - this works
  calibrationData = HW_OCOTP_ANA1;
    s_hotTemp = (uint32_t)(calibrationData & 0xFFU) >> 0x00U;
    s_hotCount = (uint32_t)(calibrationData & 0xFFF00U) >> 0X08U;
    roomCount = (uint32_t)(calibrationData & 0xFFF00000U) >> 0x14U;
    s_hot_ROOM = s_hotTemp - 25.0f;
    s_roomC_hotC = roomCount - s_hotCount;

    //time to set alarm temperatures
  //Set High Alarm Temp
  tempCodeVal = (uint32_t)(s_hotCount + (s_hotTemp - highAlarmTemp) * s_roomC_hotC / s_hot_ROOM);
    TEMPMON_TEMPSENSE0 |= (((uint32_t)(((uint32_t)(tempCodeVal)) << 20U)) & 0xFFF00000U);
  
  //Set Panic Alarm Temp
  tempCodeVal = (uint32_t)(s_hotCount + (s_hotTemp - panicAlarmTemp) * s_roomC_hotC / s_hot_ROOM);
    TEMPMON_TEMPSENSE2 |= (((uint32_t)(((uint32_t)(tempCodeVal)) << 16U)) & 0xFFF0000U);
  
  // Set Low Temp Alarm Temp
  tempCodeVal = (uint32_t)(s_hotCount + (s_hotTemp - lowAlarmTemp) * s_roomC_hotC / s_hot_ROOM);
    TEMPMON_TEMPSENSE2 |= (((uint32_t)(((uint32_t)(tempCodeVal)) << 0U)) & 0xFFFU);
  
  //Start temp monitoring
  TEMPMON_TEMPSENSE0 |= 0x2U;   //starts temp monitoring

  //PANIC shutdown:
  NVIC_SET_PRIORITY(IRQ_TEMPERATURE_PANIC, 0);
  attachInterruptVector(IRQ_TEMPERATURE_PANIC, &Panic_Temp_isr);
  NVIC_ENABLE_IRQ(IRQ_TEMPERATURE_PANIC);
}

Is Panic Temperature IRQ sets automatically even if we do not call above function from our main .ino file?
 
Sorry to revive an old thread, but I was wondering if there was any more data on the thermal performance of the Teensy 4.1?

I have been testing a 4.1 using the native ethernet, and even when doing very little (running the UDPNtpClient example and getting NTP time once ever 10s) it seems to run hot - at a room temperature of 24C the processor T quickly jumps up to 64C. Dropping the clock speed to 396MHz helps some, but it is still reaching 58C in short order.

We would like to switch to a 4.1 to replace a 3.6 and WizIO in an instrument system, but the system needs to run in the tropics and in low pressure environments (50 hPa), so I am a bit concerned about heat dissipation. Have others experienced thermal shutdowns using the 4.1 at 600MHz?
 
Sorry to revive an old thread, but I was wondering if there was any more data on the thermal performance of the Teensy 4.1?

I have been testing a 4.1 using the native ethernet, and even when doing very little (running the UDPNtpClient example and getting NTP time once ever 10s) it seems to run hot - at a room temperature of 24C the processor T quickly jumps up to 64C. Dropping the clock speed to 396MHz helps some, but it is still reaching 58C in short order.

We would like to switch to a 4.1 to replace a 3.6 and WizIO in an instrument system, but the system needs to run in the tropics and in low pressure environments (50 hPa), so I am a bit concerned about heat dissipation. Have others experienced thermal shutdowns using the 4.1 at 600MHz?

Yes, I have seen it getting too HOT even doing some other simple tasks on Teensy 4.0 (4.1 has same chip). Yes I also have got in case where Teensy was getting Thermal shutdown if I put my 4.0 in box so for now I have to run it with open area as well as not for really long time.

There is way to disable thermal shutdown if you wanted in case, but I would say that will damage chip eventually.
 
Sorry to revive an old thread, but I was wondering if there was any more data on the thermal performance of the Teensy 4.1?

I have been testing a 4.1 using the native ethernet, and even when doing very little (running the UDPNtpClient example and getting NTP time once ever 10s) it seems to run hot - at a room temperature of 24C the processor T quickly jumps up to 64C. Dropping the clock speed to 396MHz helps some, but it is still reaching 58C in short order.

We would like to switch to a 4.1 to replace a 3.6 and WizIO in an instrument system, but the system needs to run in the tropics and in low pressure environments (50 hPa), so I am a bit concerned about heat dissipation. Have others experienced thermal shutdowns using the 4.1 at 600MHz?

Did you get any solution for this issue?
 
@manitou IIRC posted power use notes on prior thread(s) - there may be more on the T_4.1 beta thread ... summary points as recalled ...

> T_4.1 alone runs using ~100 mA
> T_4.1 with onboard Ethernet activated runs using ~150 mA

@Scientist - to get better docs and some details perhaps starting a new thread specific to T_4.1 and Power/Heat with/without Ethernet in use and various speeds would be useful and get some notes on the conditions leading to the need to heat sink or cool a running Teensy 4.1. Some degree of tabulated data was produced for T_4.0 - running the benchmarks and adding USB_Host with ethernet dongle was done using float tempmonGetTemp(void) to track internal temps.

With T_4.0 beta it ran much longer and more intermediate units were delivered so internal "void tempmon_init(void)" { see ...\hardware\teensy\avr\cores\teensy4\tempmon.c } testing was done across various speeds and some testing on overclocking with heat sinks.

T_4.1 beta was much shorter with a single unit available to a few folks so that extra time and ability to lose a unit extensive testing wasn't done that AFAIK as basic functionality evolved up to production and release.

With larger board and MCU unit to spread heat at normal speed it ram below T_4.0 temps - so in basic operation without ethernet - the T_4.1 only seemed to be better to eliminate the 1062's heat.

With activation of ethernet and the current draw going up ~50% from that tiny point source - and perhaps extra active MCU parts more attention to cooling and operating temps may be needed - but it hasn't been tabulated AFAIK
 
I got curious - always a problem so I ran a few test cases:
1. Blink with prints of temp after turning on and off.
2. Demosauce on a ILI9488, every second
3. OpenGL demo on a ILI9488, every second
4. UDP with a million records (no delay)
5 UDP with a 1000 records every second

Used FBENCH to receive and transmit packets to the T4.1. Room temp about 23degsC. Heres the plot:
Capture4.jpg

As you can see it ethernet does run a few degrees hotter than other test cases but not terribly, about 4 degrees.

Differences between my temps and @Scientist tests is probably due to mounting of the T4.1. Mine is in my breakout board with some space under the T4.1 and the board.

Cheers

EDIT: At 600Mhz I have never seen a Thermal shutdown. Right now the Panic Alarm is set at 90C which for the metric challenged is 194degs F. Almost boiling.

The only time we have run into issues with thermal shut down is if we were overclocking at over 900Mhz sometimes. Easiest solution was to add a small heatsink.

EDIT2: Got curious again so ran the UDP case again at 912Mhz. The dip you see in temp is me putting my finger on the processor just to see what would happen - do not do this at home :) Most of the temp diff is due to the change in processor speed based on past testing.
Capture5.jpg
 
Last edited:
Nice work @mjs513 - we did a lot of testing like that on T_4.0 given it was new and presented more heat to touch than prior models.

Very scientifical with plotting, ambient temp, mounting notes and colors too! Only thing missing would be a ref line for a T_4.0 - it was not uncommon common for that to hit above 50°C IIRC.
 
Nice work @mjs513 - we did a lot of testing like that on T_4.0 given it was new and presented more heat to touch than prior models.

Very scientifical with plotting, ambient temp, mounting notes and colors too! Only thing missing would be a ref line for a T_4.0 - it was not uncommon common for that to hit above 50°C IIRC.

Just for you:
Capture5.jpg
 
I remember while I was getting my Ethernet library working I did notice it got pretty hot so I started printing the temps while I was doing it. I want to say it maxed out at about 67°C for me while running, simply holding my finger to the processor dropped the temps to about 55°C. I believe I did that when I was working on USB Ethernet on the T4.0 so it’s not exclusive to the built in Ethernet. I don’t think the T3.6 had a problem with it, it’s just that the higher clock speeds make the 4.0 and 4.1 run hot. If you are really worried about temps I would just place a small heat sink on it as well as a small fan and call it day.
 
These chunky copper 12x13mm units were helpful : amazon.com/gp/product/B07FTPL7Q8

They fit the outline - okay for the T_4.0 1062 and will mostly cover the 13mm 1062 on the T_4.1. Not wildly finned ( short height ) but gave some degrees drop - better with fanned air - or fan alone is better as it cools the whole board.
 
I have not (so far) had to heatsink any of my T4.0/T4.1 projects, but I've used <these> very successfully on all of my RPi projects which are in an enclosure, with airflow available/possible, but w/o an added fan. YMMV.

Mark J Culross
KD5RXT

P.S. msj513: thanks for the nice temperature graphs !!

SHUCKS !! I noticed *after* posting that these are currently shown on Amazon as unavailable. Good thing I have a healthy stash put back !! IFF they come back in stock, I would highly recommended them (I do remove the provided adhesive pads & use a good <thermal glue> to attach them to my processors permanently). MJC
 
Using 4.0 in automotive environment it runs 24/7 on CAN without issues, cabin temperatures here now with summer reached high 70's celcius, no heatsink on T4, enclosed in an atmega2560 enclosure box under the dash
 
I modified the panic temp to 100 but then the processor immediately stops after reboot. The max I can use for the panic mode is 95. The problem seems in the read value for the chip value.
If read above 95 the value gets negative. I also dis-abled the shutdown function to be able to see this. I really don't like the behavior it shuts down and does not recover at all. Could this be fixed somehow?
Thanks all.
94.33°C
94.33°C
95.00°C
-2890843392.00°C
95.00°C
-2890843392.00°C
91.63°C
 
I really don't like the behavior it shuts down and does not recover at all. Could this be fixed somehow?

If you don't want that it switches off, you must disable it.
I' wouldn't do that, but its your Teensy... :) Lets us know how long it survives!

That's what heat sinks were invented for...
 
Hi Frank,

I disabled the shutdown already and running on higher temperatures. Over 100C. I was working for NXP for a long time and we had no worries for core temperatures up 150C. Not saying I want this but do not worry at all at running around 100C. But as the reading goes to negative values above 95 I can not do this and would like to run the code as is but with panic temp set at 110 or so.
When running above 120C with a lot of cooling cycles and start cycles the only thing that will degrade is the solder joints of the BGA package....:D
 
[...] I was working for NXP for a long time and we had no worries for core temperatures up 150C. [...]
the only thing that will degrade is the solder joints of the BGA package....
biggrin.png
Interesting that NXP published a PDF which describes the degrading on higher temperaturs. Maybe you can explain this in more detail and shed some more light on it? Would be very interesting! The PDF seems to be wrong, then?
Perhaps @MJS513 can take a look at the negative Temperatures.. ? :)

2021-08-01 12_20_14-AN13122_ i.MX RT1170 product lifetimes for Industrial, Commercial, and Autom.png
Sorry, couldn't find the sheet for the 1062 now..

At the end of the day, it's meaningless what exactly degrades. The effect is the same.. it wll not work anymore.
 
Last edited:
Sure, it is to avoid that consumer products are driven outside the given specs. For this device also an automotive device is available. For this variant for example the max clock is specified at 600MHz. NXP/freescale is more worried about timing issues at high clocks. For sure this device will run in problems with timing @ high temps with a result the SW will crash. So it is a combination of degrading over time versus timing spec. (clock over lifetime so to say). For that reason you will see in the degrading specs also the max clock mentioned.

I would like a lower clock (396MHz) but have the max temp set higher as my application is running in a car and the core can exceed 90 C. and for do not want a shutdown without recovery as this would drain the battery.
 
Sure, it is to avoid that consumer products are driven outside the given specs. For this device also an automotive device is available. For this variant for example the max clock is specified at 600MHz. NXP/freescale is more worried about timing issues at high clocks. For sure this device will run in problems with timing @ high temps with a result the SW will crash. So it is a combination of degrading over time versus timing spec. (clock over lifetime so to say). For that reason you will see in the degrading specs also the max clock mentioned.

I would like a lower clock (396MHz) but have the max temp set higher as my application is running in a car and the core can exceed 90 C. and for do not want a shutdown without recovery as this would drain the battery.

If your are running TD1.54 you shouldn't be seeing a shutdown, should be seeing the T4 resetting? If you put this after Serial.begin should dump the crash settings:
Code:
  if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored.
    Serial.print(CrashReport); // Once called any crash data is cleared
    // In this case USB Serial is used - but any Stream capable output will work : SD Card or other UART Serial
  }

I also found that you have to change the panic temp in tempmon.c for it work correctly. If you want to play some there are 2 example sketches in https://github.com/PaulStoffregen/MyFault/tree/main/examples that let you override what's in tempmon.c within the sketch.

Not sure why you would be getting negative numbers, tempmonGetTemp is returning a float so should not be seeing that kind of overflow unless there is an issue with the basic conversion thats in the spec which I would have to take a look at.
 
Hi, I am currently running TD1.53. Will upgrade later today to see if that might solves some of the issues.
Thanks.
 
Hi, did the upgrade to TD1.54 and this behaves much better. But also here the max. temp that can be set for Panic is 95 C. If set higher it keeps on re-starting.
 
Hi, did the upgrade to TD1.54 and this behaves much better. But also here the max. temp that can be set for Panic is 95 C. If set higher it keeps on re-starting.

How are you setting Panic temp. You can not really do it from the sketch = you have to edit core tempmon.c. Unless you use one of the example sketched I pointed you to. Also, you can see whats causing the reset if you use CrashReport as I showed in post 46. At this point need more info to help like how you setting temp and what are you using to get the temperature as there is also another library to get temperatures.
 
If read above 95 the value gets negative.

It looks like this is caused by using unsigned integers in tempmon.c. As temperature goes up, nmeas goes down. When it gets below s_hotCount (i.e. above 95 degrees), the value goes negative, which is a large positive number due to unsigned int.

Fix is probably to change nmeas and s_hotCount to signed integers.
 
Status
Not open for further replies.
Back
Top