Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 25 of 133

Thread: Teensy 3.1 overclock to 168MHz

  1. #1
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567

    Teensy 3.1 overclock to 168MHz

    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 by Frank B; 11-13-2014 at 08:17 PM.

  2. #2
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    with a cube of dry ice on top?

  3. #3
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    It all is very stable, as usual. Nothing is warm.

    I take ice for my Bacardi :-)

  4. #4
    Senior Member
    Join Date
    Sep 2013
    Location
    Hamburg, Germany
    Posts
    891
    Quote Originally Posted by Frank B View Post
    I take ice for my Bacardi :-)
    Oh shut up I'm struggling with my last hangover!

  5. #5
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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.

  6. #6
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    Last edited by Frank B; 05-13-2014 at 05:01 PM. Reason: link change

  7. #7
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    Hi Steve,

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

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    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

  9. #9
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    Your delayMicroseconds is not correct, you can't bit shift this, it should be:
    Code:
    #if F_CPU == 120000000
       uint32_t n = usec * 40;

  10. #10
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    Thank you duff, i fixed it.

    hmm... if 144MHz are possible..or even more ? :-)

  11. #11
    Senior Member
    Join Date
    Sep 2013
    Location
    Hamburg, Germany
    Posts
    891
    If it doesn't get warm at 120 MHz, I'd definitely attach a thermometer and open the throttle!

  12. #12
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    Quote Originally Posted by Frank B View Post
    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.

  13. #13
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    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.

  14. #14
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    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..

  15. #15
    Senior Member
    Join Date
    Sep 2013
    Location
    Hamburg, Germany
    Posts
    891
    Click image for larger version. 

Name:	index.php20110724-22047-58b7hk.png 
Views:	229 
Size:	6.1 KB 
ID:	1962

    168 MHz is obscene.

  16. #16
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    St. Pauli is everywhere.

  17. #17
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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?

  18. #18
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    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.

  19. #19
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    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?

  20. #20
    Senior Member
    Join Date
    Sep 2013
    Location
    Hamburg, Germany
    Posts
    891
    Quote Originally Posted by Frank B View Post
    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.

  21. #21
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,932
    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.

  22. #22
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    Quote Originally Posted by PaulStoffregen View Post
    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 !

  23. #23
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,932
    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....

  24. #24
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,932
    Quote Originally Posted by Frank B View Post
    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.

  25. #25
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,567
    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 by Frank B; 05-13-2014 at 08:34 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •