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

Thread: Dynamic Clock Speed of Teensy 4.0

  1. #1
    Junior Member
    Join Date
    Jan 2020
    Posts
    9

    Dynamic Clock Speed of Teensy 4.0

    Hi all,

    I've been experimenting with overclocking Teensy 4.0 and I have some confusion on the correct way to change clock speed dynamically. I started off just setting the F_CPU macro which I believe is used as the frequency for the function call to set_arm_clock at startup. This updates F_CPU_ACTUAL to the correct value and when I call set_arm_clock from my code the F_CPU_ACTUAL variable updates as expected as well. Does any other code rely on the F_CPU macro being correct? Can I change the clock speed by calling set_arm_clock and not affect anything else?

    Thanks

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,498
    Quote Originally Posted by wdmerges View Post
    Hi all,

    I've been experimenting with overclocking Teensy 4.0 and I have some confusion on the correct way to change clock speed dynamically. I started off just setting the F_CPU macro which I believe is used as the frequency for the function call to set_arm_clock at startup. This updates F_CPU_ACTUAL to the correct value and when I call set_arm_clock from my code the F_CPU_ACTUAL variable updates as expected as well. Does any other code rely on the F_CPU macro being correct? Can I change the clock speed by calling set_arm_clock and not affect anything else?

    Thanks
    As far as has been discovered and documented so far - yes. The F_CPU_ACTUAL clock is suitably independent of other system clocks. Unlike T_3.x's that key off the processor clock. AFAIK the USB system only runs with the F_CPU >= 24 MHz. If there is something else lurking please post.

  3. #3
    Junior Member
    Join Date
    Jan 2020
    Posts
    9
    Looking over the core library code again that seems to be the case, the only place the F_CPU macro looks to be used is when USB is being set up. I wasn't sure if anyone had discovered any issues changing the clock like this or I missed something, thanks for the help.

  4. #4
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    What was the conclusion on this? Is there an easy way to jump to 912 Mhz for a brief period?

  5. #5
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Quote Originally Posted by jonr View Post
    What was the conclusion on this? Is there an easy way to jump to 912 Mhz for a brief period?
    Code:
    extern "C" uint32_t set_arm_clock(uint32_t frequency);
    
    void setup() {
    [...]
     set_arm_clock( 912000000 );
    [...]
    }
    ...you will notice, it shuts down due to "Temperature panic" after a some time.

  6. #6
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    Unfortunately, it creates audio glitches if one switches back and forth.

  7. #7
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Audio uses its own PLL.. hm. interesting... wonder what the reason for the glitches is.

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,498
    Don't see set_arm_clock() disabling interrupts - but clock and voltage changes might cause chip interruption/stall to DMA or other timing/processing?

  9. #9
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Sounds reasonable. The bus clock changes.

  10. #10
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    A clue: my DAC sees an interruption in toslink output. Perhaps the audio PLLs get reset?

  11. #11
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    694
    @jonr: no audio glitches here while changing CPU freq while audio is playing. I am using I2S audio with ADC PCM1808 and DAC PCM5102 with the Convolution SDR code.

  12. #12
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    Strange, that is basically the code I tested with. I just tried a different placement of the speed changes and the program locks up (switching between 816 Mhz while processing and 528 Mhz when idle and the speed at compilation was set to 600 Mhz). Most other speed combinations cause distortion. 720 when processing and 600 when idle is OK.

    Looks to me like speed changes with audio is a bad idea.

  13. #13
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Which SPDIF output do you use?

  14. #14
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    If it locks up, it might be a bus hardfault.
    Can you post a short program that locks up?
    My private core version shows such things.

  15. #15
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Ok, I tried this:
    Code:
    #include <Audio.h>
    AudioInputI2S            i2s1;           //xy=115,136
    AudioOutputSPDIF3        spdif3_1;       //xy=369,136
    AudioConnection          patchCord1(i2s1, 0, spdif3_1, 0);
    AudioConnection          patchCord2(i2s1, 1, spdif3_1, 1);
    
    extern "C" uint32_t set_arm_clock(uint32_t frequency);
    uint32_t speed = 24000000;
    
    void setup() {pinMode(13, OUTPUT);}
    
    void loop() {
      digitalWrite(13, !digitalRead(13));
      set_arm_clock( speed );
      Serial.println(speed);
      speed += 16000000;
      if (speed > 900000000) speed = 24000000;
      delay(200);
    }
    No lock... it changes the speed at intervals of 200ms, from 24MHz to 900MHz. Runs for 15 Minutes now.
    Perhaps a problem in your program? At least does does not hardfault with audio.

    As this works, I assume the SPDIF-dropouts caused by the program, too.

  16. #16
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    694
    @jonr: Ah, my fault: I was talking about underclocking from 150MHz up to 600MHz, that works properly!
    But setting it to > 600MHz with the Teensy Convolution SDR causes big problems, thats true! But its not confined to audio, also the SPI screen driver seems to get problems when overclocking.

  17. #17
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    If you guys tell me what chrashes (with a short example program) I'll look.. at the moment i think a crash of SPI is unlikely, too..
    I remember it uses an other PLL. This thingy has seven of them...

  18. #18
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    I'm using SPDIF3. It's a confusing issue because I've seen all of crashes, distorts and works fine. Distortion is the most common. I am doing a lot of processing - a simple pass-through may not trigger it.

    Confirmed, Frank's example is fine.
    Last edited by jonr; 01-22-2021 at 04:40 PM.

  19. #19
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    If the processing triggers it, the processing is the reason.. i.e. a bug in you program? SOme kind of timing problem, perhaps with interrupts.
    "pass trough" involves some processing, too. the audio library does this in software, copys the audio blocks, interleaves and deinterleaves the data, does the dma interrupts etc. it is not as simple as it looks like.
    the cpu has something to do..

  20. #20
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,367
    Quote Originally Posted by DD4WH View Post
    @jonr: Ah, my fault: I was talking about underclocking from 150MHz up to 600MHz, that works properly!
    But setting it to > 600MHz with the Teensy Convolution SDR causes big problems, thats true! But its not confined to audio, also the SPI screen driver seems to get problems when overclocking.
    I know we did some testing of chip temperature while overclocking and using a ILI9341 display. The test sketch we used was demo_sauce so overclocking shouldn't affect the display driver/SPI.

  21. #21
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Yup, and of course it's possible that the CPU gets unstable at some point.
    That's why it's called OVERclocking.. NXP says more than 600MHz is too much. You don't pack 3tons on the backseat of your car, too. The manufacturers say it's too much.
    But the runtime-change of the frequency as a cause for crashes seems unlikely to me - at the momement, until I see a program...

  22. #22
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,498
    Quote Originally Posted by Frank B View Post
    Yup, and of course it's possible that the CPU get unstable at some point.
    That's why it's called OVERclocking.. NXP says more than 600MHz is too much. You don't pack 3tons on the backseat of your car, too. The manufacturers says it's too much.
    But the runtime-change of the frequency as a cause for crashes seems unlikely to me - at the momement, until I see a program...
    Indeed it could be a chip that works well up to SPEC speed but has some temp/speed sensitive anomaly going OC.

    Adding a tempMon() print might show something.

    Putting a FAN on it will drop temp and would be an easy check if that makes a difference - small CPU type fan moving air over the whole of the board will drop temps 5-10 degrees given good ambient air temp and movement to cool the whole of the PCB to take away extra heat.

    Also possible the CPU was run OC a bit too much too fast without a heat sink and suffered early damage? Burned one up here after testing with a heat sink - a bare board got HIGH OC as the IDE was mistakenly left set in the heat sink required range and died while the heat fault got confused with bad SSD1306 code.

    Frank has made a Fault annunciator on next restart.

    @Frank - does that make a log entry for high temp? Also might be good to check in that startup code:
    Code:
    temp=tempMon()
    foo = F_CPU_ACTUAL
    if ( foo > 600 ) set_arm_clock(528'000)
    // show startup temp
    // show fault info with delay
    set_arm_clock( foo)

  23. #23
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    It switches off, i think that's the best to prevent further heating.
    Nobody knows wether it crashes again, so.. just switch off.

  24. #24
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,498
    Quote Originally Posted by Frank B View Post
    It switches off, i think that's the best to prevent further heating.
    Nobody knows wether it crashes again, so.. just switch off.
    Indeed - when it gets PANIC hot it goes too fast and off without notice as I saw. Seemed some print was noted as added - maybe a hook of the WARN temp could add a log entry? But hooking and handling that is invasive and involved.
    - my bad - but I haven't taken time to install and test that code yet ... which shows how hard it is to get excitement around it - because it seems critical to me ... but so is eating and sleeping ...

  25. #25
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Yes, it prints a message, and switches off after that

Posting Permissions

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