Teensy 4.0 Theoretical Max Clock Speed

wdmerges

Member
Hi all, I have been experimenting with the overclocking on the teensy 4.0 but didn't go above 816MHz. I was curious about what the theoretical maximum clock the hardware would support if overheating is not an issue.

I assume that the maximum voltage the board would be able to supply would affect this speed?

Thanks
 
I think this statement from page 1044 of the reference manual (Rev 1) is the one you need:
PLL1 (also referred to as ARM_PLL) - This is the PLL clocking the ARM core complex. It is a programmable integer frequency multiplier capable of output Clock Management frequency of up to 1.3 GHz. Note that this frequency is higher than the maximum chip supported frequency 1.0 GHz.

Pete
 
I've tested over 900 MHz - at a minimum a heat sink is needed, and a fan across the whole board is perhaps better - especially good in combination.

Paul has posted pics of his heat sink - seems tall thin fins - and I got a RasPi copper chunk with a grid of chunky blobs that works well enough at 916 MHz.

I plugged in a new T4 without heatsink/fan or any required cooling and using IDE that had 916 or higher 960 MHz setting I did not expect - the T4 melted inside.

It can function at or near 1008 MHz - great cooling needed and YMMV . Going over 600 MHz raises internal voltage easily from the processor's ~1.25V range - but expect shortened part life.

There is a TeensyDuino included TempMon that is of some value to print the temp - though without proper cooling rather than going up gradually through usable temp range - the temp can spike and the Teensy will restart/shutdown before going even to 50 or 60°C when normally it can operate above that temp when loaded. If that behavior is observed cool more or slow it down, and/or buy a spare T4.
 
Sounds like 1008 MHz is the max then? I am testing a liquid cooling system for the t4 but I was not sure what the max clock to test would be.

Thanks
 
In the IDE TeensyDuino 1.50 it offers 1.008 GHz - that is the max unsafe :)) ) OC Speed tested to work AFAIK. Note TD before 1.50 offered 1008MHz - but ended up with a 996MHz setting.

I suppose you've found the code set_arm_clock() for changing the speed at runtime? And are using tempmonGetTemp() to get a reading on the internal temp? With TD 1.50 the T_4 will now reset on overtemp, not just shutdown.

In some testing getting heat off the chip is good { @FRDM4236 } - maybe liquid will be enough better removing heat - but a fan cools surrounding structure so it can draw out heat as well and that is a couple degrees improved over what a heat sink was showing.
 
I've either been setting F_CPU in the Makefile or calling set_arm_clock() at runtime and monitoring tempt with tempmomGetTemp(). I'm hoping liquid will be enough to remove the heat to run stable.
 
I remember the first raspies - it was needed to burn a internal fuse to unlock overclocking.
That way, they could check the fuse when they got raspies back. If it was set, they did not refund anything.
Might be a good idea for PJRC, too.

A special program that burns a fuse (are there any fuses that can be used?) to unlock overclocking.

@wdmerges: Use dry ice :)
 
Could be a good idea, I'm not sure how often people try and refund.

Of course if I burn anything out when overclocking I would never expect a refund.
 
I don't suppose so!

But there are always people who do.
Of course this needs a fuse that can be read out when the T4 is dead... maybe on the bootloader chip?
 
The one I toasted when unmounted showed a clear internal short - you can't do that without abusing it somehow.
 
The maximum speed PLL1 can generate is 1.296 GHz. If you call set_arm_clock(1296000000), it will try to configure that speed. The CPU can't possibly run that fast... at least as far as anyone knows, based mostly on tests with heatsinks and forced are cooling. But it will try (and almost certainly crash). If you give set_arm_clock() higher numbers, it will cap your request to 1.296 GHz, because that is the maximum for PLL1.

When you try overclocking, please at least run the CoreMark benchmark to confirm the speed.

https://github.com/PaulStoffregen/CoreMark

Look at the results carefully. CoreMark checks to verify all its algorithms produced the correct results. Some speeds which are too fast (but just short of completely crashing) can actually complete the benchmark, but give wrong results. The CoreMark iterations/sec number is invalid if any of those verifications fail.

If you do get any speeds faster than 1.008 GHz to consistently pass CoreMark, I hope you'll share the results and photos of the extreme cooling used to achieve it.
 
Also the RSA test. Just before the final change to the voltage calc at or after T_4 release(?) I had one work and one fail at 800 MHz, it was likely coremark - but that was daze ago. Also ran buddabrot and maybe fastcrc - seems it was 4 total and two gave failures … before 10/8/19.

Would be interesting to see pics of the liquid cooling assembly. Just a radiator for cooling - any fan - what moves the liquid?

And it looks like I did this for loop() 10/6/19:
Code:
uint32_t ii=0;
void loop()
{
  ii++;
#if defined(__IMXRT1062__)
  Serial.printf("\n\n F_CPU=%u", F_CPU_ACTUAL );
  Serial.printf( "\tdeg  C=%u\tPass#%u\n" , (uint32_t)tempmonGetTemp(),ii );
#endif
  coremark_main(); // Run the benchmark  :-)

}
 
Hi guys, I am messing around with overclocking a T4 and managed to get it to pass CoreMark at up to 1.08GHz.

Disclamer: I did this at work where we make high performance coldplates.

I used a 10x10mm coldplate and clamped it to the Teensy with some thermal grease. The processor was also milled down about 0.009" so it would be nice and flat.
The coldplate is plumbed up to a faucet and cold tap water is used as coolant.

I ran defragster's code posted in this thread, so far it is at 120 loops (still going at the time of posting this):

Code:
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14407
Total time (secs): 14.41
Iterations/Sec   : 4164.64
Iterations       : 60000
Compiler version : GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags   : (flags unknown)
Memory location  : STACK
seedcrc          : 0xE9F5
[0]crclist       : 0xE714
[0]crcmatrix     : 0x1FD7
[0]crcstate      : 0x8E3A
[0]crcfinal      : 0xBD59
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 4164.64 / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] (flags unknown) / STACK


 F_CPU=1080000000       deg  C=25       Pass#120

The processor seems to be very sensitive to temperature-
First starting up the system the reported temperature was around 28C and the Teensy was not even able to complete the first loop at this speed.
After letting the faucet run for a few minutes to clear out the "warm" water in the buildings plumbing, the temperature had dropped to 25C and the Teensy seems to have no issue running at this speed.
I' be curious to see a temperature plot while it is actually running CoreMark.


The next clock speed increment, 1.092GHz, would not get through the first CoreMark loop with this setup.

View attachment 30319
 
OC Trial posts long ago - but not sure it ever has worked over 1.08 GHz.

Internal voltage has to rise as the speed goes up - and over max spec voltage before 1.08 GHz.

There is some cusp/spike internally when it is hot. And the critical hot spot may not be where the sensor is.

Adding CrashReport code on restart would show if it was a controlled crash with temp reported - or just locked.

Code like this in setup
Code:
void setup()
{
// ...

  Serial.begin(115200);
  while (!Serial);
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if ( CrashReport ) Serial.print ( CrashReport );

// ...
}
 
Back
Top