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

Thread: Can the F_BUS_ACTUAL (peripheral clock) be increased?

  1. #1
    Junior Member
    Join Date
    Oct 2021
    Posts
    18

    Can the F_BUS_ACTUAL (peripheral clock) be increased?

    Hi!

    Is it possible to increase the F_BUS_ACTUAL clock in order to get higher timer clocks?

    https://github.com/PaulStoffregen/co...4/clockspeed.c

    volatile uint32_t F_CPU_ACTUAL = 396000000;
    volatile uint32_t F_BUS_ACTUAL = 132000000;

    Another question: Why is the F_CPU_ACTUAL not 600MHz?

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Quote Originally Posted by 0xABCD View Post
    Is it possible to increase the F_BUS_ACTUAL clock in order to get higher timer clocks?
    Usually yes, but officially NXP says 150 MHz is the maximum peripheral clock, so technically anything faster is overclocking.


    Another question: Why is the F_CPU_ACTUAL not 600MHz?
    It is 600 MHz, unless you choose a different speed from Tools > CPU Speed.

    To confirm, just run this:

    Code:
    void setup() {
    }
    
    void loop() {
      Serial.println(F_CPU_ACTUAL);
      delay(500);
    }
    The variable is initialized to 396 MHz because the chip defaults to 396 MHz at boot. It only becomes 600 MHz when the startup code runs and programs the PLL for your clock speed.

  3. #3
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Thanks Paul for explaination!

  4. #4
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    As far as I have now understood from the code, the cpu clock and the bus clock are related by a factor of 4: F_BUS_ACTUAL * 4 = F_CPU_ACTUAL. That means, with 1008 MHz overclock I would have a 252 MHz bus clock. Should work with very good cooling?

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,274
    Indeed the BUS factors up with CPU speed.

    With enough cooling it typically works - out of spec - and hard on the chip reducing lifespan even when cool enough with higher voltage in use ... typical OC caveats.

    Fan and heat sink combo safest and measure the temps.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Quote Originally Posted by 0xABCD View Post
    Should work with very good cooling?
    There are never any guarantees or promises regarding overclocking.

    In my personal experience, 1.008 GHz wasn't reliable with a moderately sized heatsink. It got very hot.

    All substantial overclocking which has to raise the CPU core voltage can be expected to decrease the longevity of the IMXRT chip. Again, how much isn't really known. But without a heatsink, the part won't last long. As I recall, Defragster confirmed this some time ago.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,274
    Indeed changed out T_4.0 with heat sink and IDE set at ~900 MHz to a fresh bare T_4.0 without adjusting 'forgotten' clock setting.

    But was first try with an i2c display - kept hanging and assumed it was display code ... recompiled and tried diagnosing the 'display issue' and after an hour or so of that - mosyly sitting powered but idle reading code - it was burned up.

  8. #8
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,428
    You can also just decrease the divisor to two. The lets you use CPU 600MHz / BUS 300MHz, so you overclock the bus only. No overheating.
    But even that is sometimes unstable. I tried that in the T4 beta phase. If you don't use much FBUS connected periphals, it's ok. As soon you do more, it's not 100% stable anymore, and sometimes (not often) you get weird effects. I'd just try that. Or, perhaps div 3 is OK? Don't remember if that worked or was possible.

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,274
    Seems tried it at /3 to see if RAM2/DMAMEM ran faster ... didn't seem much faster and may have been some issue - so wasn't going to mention that ...

  10. #10
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,428
    200/200 or 300/300 (div1 ) could be interesting - with disabled RAM2 cache, which is not needed, then.

  11. #11
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    I have an application where I would have to count around 100 MHz with GPT1. 110MHz would be even better. If I have understood the whole thing correctly, I need a bus frequency of >=220 MHz. Right?
    Last edited by 0xABCD; 10-16-2021 at 06:36 PM.

  12. #12
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Quote Originally Posted by Frank B View Post
    You can also just decrease the divisor to two. The lets you use CPU 600MHz / BUS 300MHz, so you overclock the bus only. No overheating.
    But even that is sometimes unstable. I tried that in the T4 beta phase. If you don't use much FBUS connected periphals, it's ok. As soon you do more, it's not 100% stable anymore, and sometimes (not often) you get weird effects. I'd just try that. Or, perhaps div 3 is OK? Don't remember if that worked or was possible.
    Is it allowed to change the divisor? Then I could do CPU=450MHz (/divisor=2) -> BUS=225 MHz? Here only the bus would be overclocked. I want to count the pulses on pin 25 with GPT1 and capture the counter reading with a 2nd capture pin.

  13. #13
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,428
    Quote Originally Posted by 0xABCD View Post
    Is it allowed to change the divisor?
    No, the FBi will find you. Be warned

    For an experiment only, the easiest and fastest is to just edit this line: https://github.com/PaulStoffregen/co...ckspeed.c#L148

    ( I didn't say that... psssst )
    Print this post, and eat it.

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Early in the development of Teensy 4 (like in 2018, before the first beta test boards) I had wanted to make the CPU speed easy to change at runtime. That's why I went to so much trouble to write the set_arm_clock() function which today is in clockspeed.c. That's why all the timing code uses F_BUS_ACTUAL and F_CPU_ACTUAL.... in hope of someday making the speed easily scalable at runtime.

    But unfortunately NXP didn't give us a glitchless mux for the peripheral clock. A lingering question which I've never really had time to go back and explore, is whether we can safely change the IPG_PODF bits in the CCM_CBCDR register after peripherals are configured and running. It's just not clear to me.

  15. #15
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Hi Paul, I don't see the lack of dynamic switching options as a defect. It would only be important to be able to operate the buses at a higher frequency in order to be able to achieve higher counting rates. Would you repeat your video https://www.youtube.com/watch?v=oAUnbqK6QCY&t=454s with the Teensy 4.1?

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Quote Originally Posted by 0xABCD View Post
    Would you repeat your video ... with the Teensy 4.1?
    No, or at least not anytime reasonably soon. Those sorts of edited videos take an incredible amount of time. I'm far behind on several important software developments, and on written docs (which are also time consuming, but nothing like editing video) so I just don't have the extra hours to produce videos right now. Hope to be able to do more of those videos someday, but the realistic, that day seems to be quite a long way in the future.

  17. #17
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,428
    0xABCD Have you tried to edit the line I mentioned? Does it help for your issue?

  18. #18
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Teensy 4.1: What is wrong here? At 10 MHz I have exactly 10 MHz on the counter. Increasing the oscillator >10 MHz leads to incorrect counting results.

    Code:
    static inline void counter_init(void)
    {
      CCM_CCGR1 |= CCM_CCGR1_GPT(CCM_CCGR_ON) ;  // enable GPT1 module
      GPT1_CR = 0;
      GPT1_SR = 0x3F; // clear all prior status
      GPT1_CR =  GPT_CR_CLKSRC(3);// | GPT_CR_FRR ;// 3 external clock
      *(portConfigRegister(25)) = 1;  // ALT 1
    }
    
    static inline void counter_start(void)
    {
      GPT1_CR |= GPT_CR_EN; // enable
    }
    
    static inline uint32_t counter_read(void)
    {
      return GPT1_CNT;
    }
    
    volatile uint32_t count_ready;
    volatile uint32_t count_output;
    volatile uint32_t count_prev;
    
    void tmr_callback() 
    {
      uint32_t count = counter_read();
      count_output = count - count_prev;
      count_prev = count;
      count_ready = 1;
    }
    
    IntervalTimer it1;
    
    void setup() 
    {
      Serial.begin(9600);
      while (!Serial);
      
      analogWriteFrequency(11, 10'000'000);  // test jumper 11 to 25
      analogWrite(11, 128);
    
      Serial.print("CPU clock: ");
      Serial.print(F_CPU_ACTUAL / 1E6);
      Serial.println(" MHz");
    
      Serial.print("BUS clock: ");
      Serial.print(F_BUS_ACTUAL / 1E6);
      Serial.println(" MHz");
    
      counter_init();
      it1.begin(tmr_callback, 1'000'000);  // us
      counter_start();
    }
    
    void loop() 
    {
      if (count_ready) 
      {
        Serial.print(count_output);
        Serial.print("  ");
        Serial.print(count_output / 1E6);
        Serial.println(" MHz");
        count_ready = 0;
      }
    }
    analogWriteFrequency(11, 10'000'000); // test jumper 11 to 25
    Code:
    CPU clock: 600.00 MHz
    BUS clock: 150.00 MHz
    9999129  10.00 MHz
    10000000  10.00 MHz
    10000000  10.00 MHz
    10000000  10.00 MHz
    10000000  10.00 MHz
    10000000  10.00 MHz
    analogWriteFrequency(11, 12'000'000); // test jumper 11 to 25
    Code:
    CPU clock: 600.00 MHz
    BUS clock: 150.00 MHz
    11075439  11.08 MHz
    11076923  11.08 MHz
    11076923  11.08 MHz
    11076923  11.08 MHz
    11076923  11.08 MHz
    analogWriteFrequency(11, 15'000'000); // test jumper 11 to 25
    Code:
    CPU clock: 600.00 MHz
    BUS clock: 150.00 MHz
    8997685  9.00 MHz
    9000000  9.00 MHz
    9000000  9.00 MHz
    9000000  9.00 MHz
    Last edited by 0xABCD; 10-19-2021 at 06:42 PM.

  19. #19
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Quote Originally Posted by 0xABCD View Post
    Increasing the oscillator >10 MHz leads to incorrect counting results.
    Maybe GPT1 is running from the 24 MHz clock? Look for the PRECLK_CLK_SEL bit in CCM_CSCMR1, which is documented on page 1059 in the reference manual.

    Best to change that bit when none of the GPT or PIT (IntervalTimer) timers are active.

  20. #20
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Thanks for the reply. I added this block of code. Things get funnier @10MHz.

    Code:
      Serial.println(CCM_CSCMR1,BIN);
      CCM_CSCMR1 &= ~CCM_CSCMR1_PERCLK_CLK_SEL;
      Serial.println(CCM_CSCMR1,BIN);
    Code:
    CPU clock: 600.00 MHz
    BUS clock: 150.00 MHz
    1100110000100110000000001000000
    1100110000100110000000000000000
    1600001  1.60 MHz
    1600000  1.60 MHz
    1600000  1.60 MHz

  21. #21
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    PRECLK_CLK_SEL also changes the time base for IntervalTimer. You should be able to see the lines are now printing much faster than once per second. Of course you're seeing a smaller number if you count clock edges over less time.

  22. #22
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Also keep in mind analogWrite can only generate frequencies which are an integer division of the peripheral clock. As you use it to generate higher frequencies, remember it will round to the nearest frequency the PWM hardware can actually generate.

  23. #23
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Mission accomplished. With a higher setting, I get the correct display from an 80 MHz quartz. But I would have preferred that the clock could only be set explicitly for the specific timer and that other peripherals would not be affected. Presumably other libraries etc. are no longer running correctly.

    it1.begin(tmr_callback, 9'501'187); // us

    CPU clock: 912.00 MHz
    BUS clock: 228.00 MHz
    80009650 80.01 MHz
    80009646 80.01 MHz
    80009648 80.01 MHz

  24. #24
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,227
    Quote Originally Posted by 0xABCD View Post
    But I would have preferred that the clock could only be set explicitly for the specific timer and that other peripherals would not be affected.
    Oh how nice that would be indeed.

    Sadly, we have to just work with the way NXP wired the clock circuitry inside the chip.

  25. #25
    Junior Member
    Join Date
    Oct 2021
    Posts
    18
    Yes, the speed drives you crazy. Fortunately, the USB interface is not affected by the high bus clock rate. The question arises as to what can still be used without adjustments. Mainly because the Arduino IDE does a lot behind the scenes.

Posting Permissions

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