Overclocking The Teensy 4.1 and Teensy 4.0

Gabriel M

Member
Hey guys, I am new to this forum, and I was wondering how I would overclock the Teensy 4.1 and 4.0. Does anyone know how to do so effectively?
 
From the Arduino IDE (I'm using 1.8.19), select Tools > CPU Speed, then select the desired clock rate from the drop-down menu. Pay very close attention to the indications of the speed selections for which external cooling is required.

1737344642539.png

Mark J Culross
KD5RXT
 
good starting note @kd5rxt-mark - there were lots of notes on the T_4.x Beta threads ... went to look and didn't make it back.

Things seem to work without problems at elevated speeds. It should be expected to shorten the life of the unit as the added voltage and heat are beyond design limits, and if heat builds it can halt for over temp (or worse), most notably where cooling is noted as required.

Not sure how much OC was considered? Notes left in Beta thread were that heat sink alone was helpful to a point - fan was better - together was best. T_4.1's larger PCB seemed to dissipate heat better than the smaller T_4.0.
 
@kd5rxt-mark Thank you for that, I see it on my computer too, and I have the newest edition of the Arduino IDE. I was wondering, is there a way that I can make a program that would adjust and change the clock speed of the processor through code? Like could I write code that could change the clock speed instead of manually doing it each time?
 
good starting note @kd5rxt-mark - there were lots of notes on the T_4.x Beta threads ... went to look and didn't make it back.

Things seem to work without problems at elevated speeds. It should be expected to shorten the life of the unit as the added voltage and heat are beyond design limits, and if heat builds it can halt for over temp (or worse), most notably where cooling is noted as required.

Not sure how much OC was considered? Notes left in Beta thread were that heat sink alone was helpful to a point - fan was better - together was best. T_4.1's larger PCB seemed to dissipate heat better than the smaller T_4.0.
From this I am getting that it is not recommended to overclock either Teensy 4.1 or 4.0 for extended periods due to shortly life spans of the processor? I am also getting that the Teensy 4.0 might hold more heat due to it having a smaller board and not being able to dissipate heat as fast as the Teensy 4.1?
 
The Teensy4 core contains the function below, which lets you set the clock and does its best to keep all of the peripherals working correctly, for example UART baud rates. It's not clear to me calling this function is 100% equivalent to setting CPU frequency via the IDE, but I have used it to reduce the CPU frequency and it does work. Note that the core contains variables F_CPU_ACTUAL and F_BUS_ACTUAL. Despite their being all caps, they are variables, not macros, and they are updated by set_arm_clock().

Code:
uint32_t set_arm_clock(uint32_t frequency)
 
From this I am getting that it is not recommended to overclock either Teensy 4.1 or 4.0 for extended periods due to shortly life spans of the processor?

Confirm, overclocking is likely to shorten the hardware lifespan. How much, nobody really knows. Better cooling helps, but exactly how much is also not really well known.

According to an NXP app note, underclocking to 528 MHz may lengthen the chip's life span. But even that info is difficult to apply to realistic scenarios, because they test with the chip running at the extreme upper temperature.

You're simply not going to find a highly definitive answer about the actual precise effects of overclocking. If you decide to overclock, you're straying off the path of definitive specifications published by a major corporation (NXP) which are presumably backed up by rigorous design and testing. If you're not mentally prepared for uncertainty, you probably should stay within the official published specs.
 
FWIW - I have been running my Teensy 4.1at 816Mhz for 4-5 years now, for long periods at a time each use. All my Teensys subjected to this are still operational. I have a small (10mm x 10mm x 4mm) cheap, copper heatsink sitting on the processor chip and the Teensy is squished between two PCBs, the upper PCB has a 4" screen and lower PCB has other associated components needed for my project. So, not fully enclosed, but not fully open to the air, either. Temperature as measured by tempmon usually hovers around 53°c. I use a custom function to wrap set_arm_clock to change clock frequency on the fly - during startup, when entering/leaving sleep mode and also user-selectable from my UI when I want to try out certain things - again, on the fly. Generally, changing CPU speed when running works fine - only issues I've seen with changing clock speed on the fly are when using FlexIO to drive a parallel screen, and also when setting it to above around 850Mhz, I get crashes which may or may not be due to additionally overclocking PSRAM to 180/198Mhz - yet to spend time diagnosing this. Obviously, my use cases are a fraction of all the possible use cases so I can't state the impact on changing clock speed on the fly has on other operations but for the things I'm doing - reading/writing to an SD card, driving a parallel screen over GPIO, driving a GUI via LVGL, reading the ADC, using the Audio lib to play sounds, take I2S input, etc. I haven't experienced many issues.

EDIT - I have functionality in my code to detect the presence of a CrashReport on startup, before setting CPUSpeed and any other parameters I use for overclocking peripherals, such as PSRAM and SDcard - if CrashReport detected, I set them to defaults rather than my user selected values, so I don't get stuck in a bootloop, in case the values are what are causing the crash.

Overclocking any tech introduces risks, but it's all about your personal risk appetite - if my $30 T4.1 has a 'shortened' life beyond it's current 5 years due to running at 816Mhz, I'm good with that.
 
Last edited:
Have not seen anyone else admit to burning one up - but one did here in about an hour.

IDE was set to OC for a cooled unit. Didn't notice/change that and plugged in 'NEW' T_4.1 with NO cooling provisions - it was acting funny ... kept reprogramming and running trying to see it work right with simple sketches ... then it stopped working :(

In the BETA OC testing the temps could zoom through 55° and then crash - what is reported may be stale - or not the hottest part of the chip. Sometime the last temp number seen was higher or lower IIRC.

A metal heatsink like @beermat indicates may help distribute the heat from the hottest part - as noted it helps and sounds simlar to the base unit used here (a RasPi kit Cu blob)- @PaulStoffregen pictured a large finned unit once that he had even better luck with it seems.
 
Confessions are good for the soul! Sorry for your loss :(

I don't use the IDE setting (or rather, have it set to 600), just what I set in code. I poll the tempmon each second and have a graph overlay available that stays on top of my UI showing the temp, useful when I was testing more. My UI also doesn't let me set above 912MHz, and I have code that dials the CPU back to the default if the temp polling shows a temp above a predefined value.Settings UI below, showing 70c as that value.....I'll take the risks, but code in some risk mitigation..

20250120_163526_565.png


Isn't there a default shutdown built in for 95c?
 
Watching CrashReport on restart to avoid triggering is a good plan. Might be nice to have CrashReport return the exception # stored instead of a binary? The code might be interested in knowing that when no SerMon online?

When temp starts to run away it goes fast without cooling and in those cases last temp reported may be under 60° before exception triggers.

As soon as exception is triggered F_CPU is dropped to 300 MHz in case it allows enough recovery to finish the handler ... IIRC.

This burned unit was T_4.0 in early days - while it was being first explored - and it was not thought out :) Actually it was a T_4.0 just soldered to a FRDM4236 board to bring out most all the pins from a T_4 to a larger T_3.6 factor before T_4.1 was introduced. Soldering to that board was a good distraction - thinking the castellated solder of the underside was behind the 'odd' behavior.
 
Confirm, overclocking is likely to shorten the hardware lifespan. How much, nobody really knows. Better cooling helps, but exactly how much is also not really well known.

According to an NXP app note, underclocking to 528 MHz may lengthen the chip's life span. But even that info is difficult to apply to realistic scenarios, because they test with the chip running at the extreme upper temperature.

You're simply not going to find a highly definitive answer about the actual precise effects of overclocking. If you decide to overclock, you're straying off the path of definitive specifications published by a major corporation (NXP) which are presumably backed up by rigorous design and testing. If you're not mentally prepared for uncertainty, you probably should stay within the official published specs.
Okay, thank you for this information! I really appreciate you guys for helping me out and providing all of this information.
 
Confessions are good for the soul! Sorry for your loss :(

I don't use the IDE setting (or rather, have it set to 600), just what I set in code. I poll the tempmon each second and have a graph overlay available that stays on top of my UI showing the temp, useful when I was testing more. My UI also doesn't let me set above 912MHz, and I have code that dials the CPU back to the default if the temp polling shows a temp above a predefined value.Settings UI below, showing 70c as that value.....I'll take the risks, but code in some risk mitigation..

View attachment 36729

Isn't there a default shutdown built in for 95c?
Not all ARM processors sport a integrated temperature sensor, including the ARM Cortex M7 processor that NXP made that is used on both the Teensy 4.1 and 4.0 or at least this is what I learned from researching online.
 
FWIW - I have been running my Teensy 4.1at 816Mhz for 4-5 years now, for long periods at a time each use. All my Teensys subjected to this are still operational. I have a small (10mm x 10mm x 4mm) cheap, copper heatsink sitting on the processor chip and the Teensy is squished between two PCBs, the upper PCB has a 4" screen and lower PCB has other associated components needed for my project. So, not fully enclosed, but not fully open to the air, either. Temperature as measured by tempmon usually hovers around 53°c. I use a custom function to wrap set_arm_clock to change clock frequency on the fly - during startup, when entering/leaving sleep mode and also user-selectable from my UI when I want to try out certain things - again, on the fly. Generally, changing CPU speed when running works fine - only issues I've seen with changing clock speed on the fly are when using FlexIO to drive a parallel screen, and also when setting it to above around 850Mhz, I get crashes which may or may not be due to additionally overclocking PSRAM to 180/198Mhz - yet to spend time diagnosing this. Obviously, my use cases are a fraction of all the possible use cases so I can't state the impact on changing clock speed on the fly has on other operations but for the things I'm doing - reading/writing to an SD card, driving a parallel screen over GPIO, driving a GUI via LVGL, reading the ADC, using the Audio lib to play sounds, take I2S input, etc. I haven't experienced many issues.

EDIT - I have functionality in my code to detect the presence of a CrashReport on startup, before setting CPUSpeed and any other parameters I use for overclocking peripherals, such as PSRAM and SDcard - if CrashReport detected, I set them to defaults rather than my user selected values, so I don't get stuck in a bootloop, in case the values are what are causing the crash.

Overclocking any tech introduces risks, but it's all about your personal risk appetite - if my $30 T4.1 has a 'shortened' life beyond it's current 5 years due to running at 816Mhz, I'm good with that.
Could you maybe share some code with me for changing the clock speed, please? If you want of course.
 
The Teensy4 core contains the function below, which lets you set the clock and does its best to keep all of the peripherals working correctly, for example UART baud rates. It's not clear to me calling this function is 100% equivalent to setting CPU frequency via the IDE, but I have used it to reduce the CPU frequency and it does work. Note that the core contains variables F_CPU_ACTUAL and F_BUS_ACTUAL. Despite their being all caps, they are variables, not macros, and they are updated by set_arm_clock().

Code:
uint32_t set_arm_clock(uint32_t frequency)
Do I need any libraries for this, or is this line of code all I need to change the clock speed? And are there any limitations to the clock speed number? other than what is given as a minimum and maximum clock speed for the processor of course. (184KHz-1.008GHz)
 
Not all ARM processors sport a integrated temperature sensor, including the ARM Cortex M7 processor that NXP made that is used on both the Teensy 4.1 and 4.0 or at least this is what I learned from researching online.
It's not part of the CPU, it's one of the modules that NXP included in the microprocessor. As previously mentioned it is activated by the default startup code with a panic temperature setting of 90C.
 
It's not part of the CPU, it's one of the modules that NXP included in the microprocessor. As previously mentioned it is activated by the default startup code with a panic temperature setting of 90C.
So the chip does include a integrated temperature sensor, just not in the CPU itself? Because I do know the processor entirely is composed of a CPU and NPU.
 
There is so much more inside the IMXRT chip than just the CPU.
What else is inside the chip? So far I know a CPU, NPU and a Temperature sensor, do you mind listing maybe some more features I don't know about? Kind of got me excited, maybe I got more that what I thought I got.
 
do you mind listing maybe some more features I don't know about?

Sure, there are 3 main lists of the features.

1: The Teensy 4.1 product page has a long list of many features. Just scroll down and start reading. For example, the Communication section explains the 8 main ways the hardware is capable of communicating data with other things.

2: NXP's reference manual has detailed documentation. On the product page, scroll down to "Technical Information". It's the first link. It's also the same as the answer in msg #19 from jmarsh and msg #21 from kd5rxt-mark. For a brief list, you could look at section 2.2 "Features" on pages 31-33, or the block diagram on page 30. Or just look at the names of the 68 chapters, as each type of peripheral within the chip has its own chapter. Most chapters begin with a 1-2 page list of features within that specific peripheral.

3: Chapter 28 in NXP's manual explains the Cortex M7 processor. But it's only a very brief 7 page summary. The CPU comes from ARM and has thousands of pages more documentation published by ARM. In those Technical Info links on the product page, you can find a few different links to the info from ARM. The easiest to read is unfortunately not free, but well worth the cost if you *really* want to learn the inner working of the ARM Cortex-M processor. Amazon usually lets you view every book's the table of contents for free, so that might be an effective way to get just a list of the major features within the ARM Cortex-M7 CPU. Or you could dive into ARM's free documentation, but honestly it's a pretty steep learning curve to climb if you're not already familiar with how things work (likely by either reading that book or experience from other ARM chips).

Admittedly this is list of the lists of features rather than just a simple list as you requested, but hopefully it helps you find the info you wanted.
 
Last edited:
Back
Top