Teensy 3.1 overclock to 168MHz

PaulStoffregen said:
Also, with overclocking, consider that 144 and 168 MHz modes overclock the flash memory. 144 MHz mode overclocks the flash by 20% and 168 MHz overclocks it by 40%.

168 MHz mode also overclocks the peripherals by 17%.

120 MHz mode runs the flash memory within spec, but overclocks peripherals by 25%.

96 MHz mode runs the flash and peripherals within spec, and it's only a modest overclock of the CPU. I personally test nearly all code at 96 MHz and everything has worked very well at this speed.

But technically, anything over 72 MHz on Teensy 3.1 and anything over 48 MHz on Teensy 3.0 is overclocking.
Click to expand...

How does this affect delay(), micros(), millis()?

I´m trying to calculate FPS. This code outputs ~ once a second. I´m getting 16-17 FPS.
Can this be?

Why does it need an offset of ~9000ms?

Code: 
void loop(void) {
  long t = 0;
  long start_t = millis();
  int sec = 9000;
  int i = 0;
  
  while(1) {
    //tft.setRotation(rotation);
    testText();
    //delay(1000);
    
    t += (millis() - start_t);
    i++;
    if (t >= sec){
      t -= sec;
      Serial.print(F("FPS: "));
      Serial.println(i);
      i=0;
      start_t = millis();
    }
  }
}

Code: 
ILI9341 Test!
Display Power Mode: 0x0
MADCTL Mode: 0x0
Pixel Format: 0x0
Image Format: 0x0
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              224096
Text                     16712
Lines                    58739
Horiz/Vert Lines         18570
Rectangles (outline)     11750
Rectangles (filled)      465397
Circles (filled)         79067
Circles (outline)        81241
Triangles (outline)      14294
Triangles (filled)       159296
Rounded rects (outline)  33748
Rounded rects (filled)   510878
Done!
FPS: 17
FPS: 16
FPS: 16
FPS: 16
FPS: 17
FPS: 16
FPS: 16
FPS: 16
FPS: 16
FPS: 17
FPS: 16
FPS: 16
FPS: 16
FPS: 17
FPS: 16
FPS: 16
FPS: 16
FPS: 16
FPS: 17
FPS: 16
 
Last edited:
origami said:
How does this affect delay(), micros(), millis()?
Click to expand...

The hardware timers automatically reconfigure, so you always get 1ms and 1us, regardless of the CPU speed.

Well, plus a tiny amount of code execution overhead in the call and return, which obviously does improve with clock speed.

I´m trying to calculate FPS. This code outputs ~ once a second. I´m getting 16-17 FPS.
Click to expand...

For SPI-based displays, you'll probably see best performance at 120 MHz, if your display can handle 30 MHz SPI clock.

The maximum SPI clock is F_BUS/2. F_BUS has to be an integer divide of F_CPU. When F_CPU is 144 MHz, F_BUS is 48 MHz (divide by 3). However, when F_CPU is 120 MHz, F_BUS is 60 MHz (divide by 2)... so you can get faster SPI data transfer at 120 MHz than you can at 144 MHz.
 
PaulStoffregen said:
For SPI-based displays, you'll probably see best performance at 120 MHz, if your display can handle 30 MHz SPI clock.

The maximum SPI clock is F_BUS/2. F_BUS has to be an integer divide of F_CPU. When F_CPU is 144 MHz, F_BUS is 48 MHz (divide by 3). However, when F_CPU is 120 MHz, F_BUS is 60 MHz (divide by 2)... so you can get faster SPI data transfer at 120 MHz than you can at 144 MHz.
Click to expand...
Indeed 96 and 144 MHz have almost the same results
Code: 
                       	96 Mhz	120 Mhz	144 Mhz
			
Screen fill         	280148	224147	280108
Text              	19602	16714	16412
Lines                 	73320	58736	73112
Horiz/Vert Lines      	23153	18571	23057
Rectangles (outline)	14668	11748	14635
Rectangles (filled)	581709	465393	581661
Circles (filled)      	95745	79087	90845
Circles (outline)	96136	81252	76478
Triangles (outline)	17805	14290	17719
Triangles (filled)	197576	159282	194515
Rounded rects (outline)	40185	33739	34236
Rounded rects (filled)	637565	510878	635961


PaulStoffregen said:
The hardware timers automatically reconfigure, so you always get 1ms and 1us, regardless of the CPU speed.
Click to expand...
The thing is though, if I run the modified code with 1000ms to get FPS, I get several outputs per second. I need to wait ~9000ms "Teensy-time" (int sec) to get output once per second :confused:
 
Last edited:
This turbo overclock should come as an option with the Teesny loader, why not? I mignt be underestimating and unaware of the dangers that pose when overclocking microcontrollers.
 
In the grand scheme of things, you're overclocking a $20 microcontroller board. People overclock their several hundred dollar graphics cards and PC motherboards all the time. Much like PC overclocking, theoretically you're risking the hardware, but actual damage is very rare. Usually the processor just locks up or does wrong things, but usually works fine when you run again at lower speeds.

When you press the button on Teensy 3.1, the Mini54 takes over. It hard resets the MK20 chip. When your finger releases the button, the Mini54 starts it up again at only 24 MHz. This always should recover from overclocking crashes. Well, unless the chip got damaged, which it theoretically possible but very unlikely.

168 MHz is not very stable. Reports are mixed on 144 MHz. Many people say it's working well, but a few have reported crashes after long periods. So far, consensus seems to be 120 MHz works very well.

120 MHz is also a bit special. Even though the CPU isn't as fast as 144 or 168, this speed has the fastest peripheral clock, because that clock must be an integer divide of the CPU clock. If your project is I/O bound, especially with SPI, this speed can let you get 30 MHz SPI clock rates, instead of the usual 24 MHz maximum. Sometimes that matters more than the CPU speed.
 
The memory, flash, and peripherals run at a much slower speed. They also usually all run at different speeds too.
So there is a trade-off when going at that speed.
The idea though, is that if you can keep a small computational intense loop in the cache, you will see a benefit. The trick is to avoid memory cache misses. Access to memory that causes a cache miss will gain you nothing. So it would break-even. This is usually the case for most code.
Now the bad news...
Accessing I/O may in fact get slower, depending on the wait states and I/O clocking.
 
The RAM runs at the full CPU speed. Flash runs much slower.

There's a "FASTRUN" feature that lets you put your speed critical functions into RAM. It rarely makes much difference at normal speeds, but at 144 or 168 it can have a much more dramatic effect.
 
Yes, but to interpret the results you must know what are you measuring. If there are library-calls or floating-point calculations for example, they will run from flash, despite of "FASTRUN".

168MHz had never been stable on my Teensys. 144MHz is ok for mine.
Is there an option to tune the voltage on the 3.1 ? maybe one could try that... if possible.
 
PaulStoffregen said:
The RAM runs at the full CPU speed. Flash runs much slower.

There's a "FASTRUN" feature that lets you put your speed critical functions into RAM. It rarely makes much difference at normal speeds, but at 144 or 168 it can have a much more dramatic effect.
Click to expand...

Running the FFTs with FASTRUN (i.e. tables and code in Memory) at 144 MHz, makes a significant difference.
 
Yes, it can be a mixed bag.
Generally it isn't worth doing. In my experience, regardless of the price.
Even with the Teensy 3/3.1, I've seen I/O actually get slower. It depends totally on the divisors though, and we know that.
I suggest like Paul... but from a different perspective.
Think of it this way: Yes you COULD load 100 people onto a car, strapping them to various parts of the body of it, but are you willing to risk the passengers?
as compared to: Yes you COULD overclock the MCU or CPU, but are you willing to risk the possibility of the program running incorrectly?
 
I'm very comfortable with 96 MHz.

All the Kinetis chips are made with the same 90 nm process. There's also very good reason to believe the 72 MHz parts are the same or a very similar design as the ones rated for 100 MHz.

The other options are commented out in boards.txt. Perhaps 168 should be removed?
 
PaulStoffregen said:
I'm very comfortable with 96 MHz.

All the Kinetis chips are made with the same 90 nm process. There's also very good reason to believe the 72 MHz parts are the same or a very similar design as the ones rated for 100 MHz.

The other options are commented out in boards.txt. Perhaps 168 should be removed?
Click to expand...
I would say "yes".
 
Frank B said:
I would say "yes".
Click to expand...

I actually agree on this point. 120 is actually what I tend to find works very well... I also actually use other 120MHz Kinetis MCU as well, same family infact. What I find interesting about them though is that you can't overclock those.
It would seem to me that Freescale does like everyone else does... some chips won't be able to reach the higher speeds reliably, so they are badged as a lower speed after using some form of HV secret sauce programming.

What this all means is that you may get chips that can exceed the ratings, sometimes because a lower speed is more in demand, but what ones will do this reliably can be quite random, even from the same lot and wafer.
 
Adding a 120 MHz overclock option will certainly be awsome! I get a general picture based on this thread that most people agree that overclock at 120MHz can cause some turbulence but never a plane crash. At least when compared to what the higher overclock speeds (<120MHz) can cause.
 
@mixania: all you need to do is editing robots.txt, there are already options for 120MHz. Just remove the comments.

Yes, i ran my mp3-player on 120mhz for days without crash or warmth
 
Yes, but it should come with a cautionary note and not be a "supported" option.
in fact I personally would not support any of the overclocked speeds.
What I mean by support is that if your stuff does not work at the higher speed, then PJRC is not responsible for it not working.
It is a hack and thus fully disclosed as such, with no promises that it will actually work every time, in every situation.
There are a multitude of problems that can occur just by certain sequences on the data bus, for example, that could cause an electron to jump onto the wrong pathway, thus crashing your program.

Generally, I think one of the requirements for posting a "bug" is to make sure the same thing happens at the rated speed of the chip.
If things work at the lower speed, you've found the "bug"... I've actually encountered this, across many platforms in the past.
 
You must log in or register to reply here.
Back
Top