Teensy 3.1 overclock to 168MHz

Frank B

Senior Member
EDIT: This is already in Teensyduino 1.19 and up.
Don't use my repository @ github anymore.




Hi,

i successfully overclocked my teensy 3.1 to 120 MHz.
Busclock is 40MHz, Flash 30MHz.

If anyone is interested, I can upload the changes at github.
Additionally,i changed some of the GCC - switches for speed-optimization, not size.

120 is easy selectable:Tools -> CPU Speed -> 120 MHz(Overclock TURBO)

Regards,
Frank

Edit: Runs for 18 Hours now, without any problem.

Edit: Download is here, now with 120MHZ || 144MHz || 168MHz
 
Last edited:
GCC switches... Is there a way to enable the C99 standard for Teensy 2/AVRs given the Arduino 1.0.x we're still using omits that standard?
Mainly so I get struct initializers with member names. Teensy 3's GCC version/command line does enable C99 support.

And with that, the same source can be used for both Teensy 2 and 3.
 
Hi Steve,

i hav'nt looked at Teensy 2, but in boards.txt you can add switches. I would give it a try..
 
One thing, i forgot to mention:

There's an issue with PWM and SPI, a fix should be easy, i did not fix this it because i don't use PWM/SPI
 
Your delayMicroseconds is not correct, you can't bit shift this, it should be:
Code:
#if F_CPU == 120000000
   uint32_t n = usec * 40;
 
hmm... if 144MHz are possible..or even more ? :)

looks like you could over clock it all the way to 220MHz if you set the vdiv0 to the max, though i have no clue if that is safe or not.

While writing my low power library i spent a good amount of time on delayMicroseconds but i was going the other way. I'm interseted in making it possible to change the speed dynamically but its really hard beacuse paul has optimized the functionalities for using F_CPU, F_BUS, F_MEM, that getting the same code performance is beyond my skill set currently.;)
 
Christoph:)

Ok... i have WARP3 216MHZ running. Still cold and stable, but without USB. The divisor is only 3 Bit and USB needs 48MHz
Fastest with USB is WARP1 168MHz.

Duff, yes, to do this dynamically is tricky.
 
Ok, i just uploaded a version with 168MHz Core, 42MHz Bus and 28 MHz Flash. It is rock stable so far.

Eventually, i'll fix PWM/SPI the next days..
 
index.php20110724-22047-58b7hk.png

168 MHz is obscene.
 
Maybe no heat rise (as in an AMD/Intel x86) but I'd think you'd reach a limit at the flash or RAM cycle times? Or are they held constant despite the speedup?
 
They are more or less constant for the different core-speeds. At 168MHz, the flash-clock is only a little bit faster (28MHz) than standard 24MHz.
Code:
#if (F_CPU == 168000000)
 #define F_BUS 42000000
 #define F_MEM 28000000
#elif (F_CPU == 144000000)
 #define F_BUS 48000000
 #define F_MEM 24000000
#elif (F_CPU == 120000000)
 #define F_BUS 40000000
 #define F_MEM 30000000
#elif (F_CPU == 96000000)
 #define F_BUS 48000000
 #define F_MEM 24000000
#elif (F_CPU == 48000000)
 #define F_BUS 48000000
 #define F_MEM 24000000
#elif (F_CPU == 24000000)
 #define F_BUS 24000000
 #define F_MEM 24000000
#endif

F_MEM is the flash-timing.

If you want it "original", you can use 144MHz.
As far as i know, RAM hast the same timing as the core, so at 168MHz it is clocked with 168MHz too. I don't think that this is a problem, since it is on the same silicon as the core (Rasperry uses an ""extra" piece of silicon for this)
Anyway, the best is, to try it out :) My teensy is running a benchmark for some hours now at 168MHz and shows no problem.
 
Hi all,
the issue PWM / SPI should be fixed. Can't test this at the moment.
The frequency is at 168MHz/120MHz a bit slower, because of slower F_BUS. If you want original timings, use 144MHz !

Has anyone tried the new speeds?
 
Has anyone tried the new speeds?

Not yet for the following reason: I'm not sure what changes I made in my current mk20dx128.c. When I replace it with yours and get any errors, I'll have a hard time finding out what the root cause might be. Stay tuned, though, I'm above 50% CPU load in my project and it took me only a week to get it that high.
 
Has anyone tried 192 MHz?

192 MHz would allow creating a low jitter MCLK for I2S audio. The audio library is also the place where you really would want more CPU power. The 1024 point FFT object (which I just committed to github last night) uses about 50% of the CPU at 96 MHz. That usage is one of every 4 updates, so it's theoretically possible a LOT of coding would could distribute the load and get the CPU peak usage into the 12-15% range. Whether any ever does that is a good question.

I should also point out the heating of the chip appears to be related much more to bus & DMA activity than CPU-only activity. The 4320 LED demo we just built for Maker Faire gets the chip pretty warm... much moreso that anything I've ever done before. It's running at 96 MHz.
 
Has anyone tried 192 MHz?

192 MHz would allow creating a low jitter MCLK for I2S audio. The audio library is also the place where you really would want more CPU power. The 1024 point FFT object (which I just committed to github last night) uses about 50% of the CPU at 96 MHz. That usage is one of every 4 updates, so it's theoretically possible a LOT of coding would could distribute the load and get the CPU peak usage into the 12-15% range. Whether any ever does that is a good question.

I should also point out the heating of the chip appears to be related much more to bus & DMA activity than CPU-only activity. The 4320 LED demo we just built for Maker Faire gets the chip pretty warm... much moreso that anything I've ever done before. It's running at 96 MHz.

I have not managed to make 192 MHz work with USB. Maybe I did something wrong...

Teensy was never warm for me.
But I only have had the CPU busy. Thanks for the note !
 
For stress testing, I'd recommend incorporating OctoWS2811 into your benchmark. Use 800 for the number of LEDs per strip. Fill the drawing buffer with 0x55 in every even byte and 0xAA in every odd byte address (or write 0xAA55AA55 to every 32 bit integer), so the 8 output pins toggle at maximum speed. You can use an IntervalTimer to call leds.show() every 50 ms. That should keep the DMA engine and GPIO busy while your benchmark ties up the CPU. My understanding of this chip is a separate bus structure tying the RAM to the CPU, so a big OctoWS2811 workload should keep those other buses really active.

On OctoWS2811, and a lot of other things, timings will probably be wrong it F_BUS is anything other than 48 or 24 MHz. For example, this in pins_teensy.c

Code:
#if F_BUS == 48000000
#define DEFAULT_FTM_MOD (49152 - 1)
#define DEFAULT_FTM_PRESCALE 1
#else
#define DEFAULT_FTM_MOD (49152 - 1)
#define DEFAULT_FTM_PRESCALE 0
#endif

I'd like to start expanding these many places to handle other bus and cpu frequencies. Pull requests are welcome....
 
I have not managed to make 192 MHz work with USB. Maybe I did something wrong...

If the PLL is running at 192 MHz, I would imagine this should do it:

Code:
    SIM_CLKDIV2 = SIM_CLKDIV2_USBDIV(3);

Then again, it's possible 192 MHz is simply too fast.
 
I can do a pull request for the core, but i have "incompatible" F_BUS - 40 MHz & 42 MHz in - for 120 & 168 MHz. 144 MHz should work perfect.
 
Last edited:
Back
Top