T4 Increasing the clock speed

Status
Not open for further replies.

barhirsh

New member
Hi.
For the project I am doing I want to increase the clock speed of the T4 for a short time (less than a second). Is there a programming option so that the T4 will increase the clock speed and then decrease it?
In addition, will it affect timers or analog readings and digital outputs?
 
The answer really depends on what's meant by "programming option". If you're looking for a reliable, well tested and well supported function, then the answer is no.

But if you want to dive into using a function which was originally meant to do this dynamic clock scaling, but was never really tested beyond a limited scope of just setting the speed once at startup, then arm_set_clock() in clockspeed.c is the programming option you seek!

Yes, changing the clock speed will affect the ADC, some timers, and probably lots of other stuff too. But many of the peripherals run from their own clocks which are controlled independently from the processor's clock and main peripheral clock. So a lot of timing sensitive stuff like serial port baud rates will remain consistent. But PWM frequencies and ADC measurement will be affected, since those run from the main peripheral clock which is always synchronous to the processor clock. Many parts of the core library use F_CPU_ACTUAL rather than F_CPU to automatically adapt to the new speed. The original idea was to support dynamic clock scaling at runtime. It's a dream that so far has never fully been realized...

The biggest issue it what happens if peripherals are using the clock while you change it. I'm sad to say NXP did not give us a glitch-free mux for the peripheral clock. If you read the manual, it talks of hardware being "harmed" if you change the clock while it's being used. So far I've never seen permanent damage. But while experimenting early in the Teensy 4 development, I did lock up the whole chip pretty badly a few times. A complete cold restart (allowing the SNVS voltage to get all the way down to zero) always seemed to bring it back to life.

If you do play with arm_set_clock() after startup, I'm curious to hear about your experience. Someday I would love to support dynamic clock scaling. It's one of so many things that were imagined but never completed in the rush to get Teensy 4.0 released (only months before the pandemic hit - stalling most dev work).
 
If you do play with arm_set_clock() after startup, I'm curious to hear about your experience.
Paul, does the above apply to the Teensy 4.1 as well? I have been using arm_set_clock() in my main project running on a T4.1 for almost a year, and haven't once experienced/identified any negative effects related to using this, at least that I have noticed, with the processor or any peripherals in use. It is a user changeable setting in my app from 20-816Mhz; I frequently change it manually "on the fly" to see it's impact on power consumption, UI update speed, ADC library read speed, video playback speed, etc. Additionally, I have a user defined setting for "power saving" which after a period of time, turns off the screen and steps to a lower CPU speed; a touch on the TFT returns it back to the "normal" speed, and have never seen any issues related to this during operation.

Peripherals/functions/libraries used in the app include I2S2 audio in/out, SPI (for touch screen and a digital potentiometer control), GPIO6 for 8/16 bit parallel TFT screen writes/read, bit-banged I2C reading an INA219 current sensor, Serial8 for TF02-Pro distance sensor, NativeEthernet, LVGL graphics library v7.x, and intervalTimer amongst others, and all seem to function correctly after calling arm_set_clock()

General application use makes very few calls to this, however. Mostly switching to the user defined CPU speed read from EEPROM on startup and switching in and out of "low power" mode. However, on startup, my app can programmatically walk through a small loop reducing CPU speed in steps if TFT initialization fails, to retry initialization at a slower CPU speed. This is mostly due to the Teensy operating too quickly for the NT35510 screen controller at higher CPU frequencies and me constantly tweaking the number and locations of NOPs in my driver to squeeze maximum performance out of it, and sometimes getting it wrong...this looping doesn't seem to cause any issues, either.

For me, your dream to support dynamic clock scaling at runtime is actually a reality.
 
For me, your dream to support dynamic clock scaling at runtime is actually a reality.

Good to know it's working for you. We don't really promote using this at runtime yet, because it just hasn't been tested much.

And yes, confirm what Defragster said, it's the same on both 4.0 & 4.1.
 
I just tried arm_set_clock() with a T4 USB audio to spdif application and it was completely unusable. This was with rapid changes - fast while calculating, slower while idle.

What is successful is using asm volatile ("wfi");. This allows running at 720Mhz while running cooler than 600Mhz.
 
Last edited:
> using asm volatile ("wfi")

After more testing, this eventually causes the teensy to crash and reload firmware. Might be some interaction with power saving timeouts on the PC.

Has anyone successfully used "wfi" to save energy in an audio processing application?
 
> using asm volatile ("wfi")

After more testing, this eventually causes the teensy to crash and reload firmware. Might be some interaction with power saving timeouts on the PC.

Has anyone successfully used "wfi" to save energy in an audio processing application?

Not seen a lot of ref to "wfi" with T_4.x's. It sleeps until the next _isr() triggers where the usual Millis_Timer_Tick does not count on T_4.x.

With Audio it has interrupts ... but also active DMA ? ...

Interesting question what those ongoing things do between interrupts when the CPU goes into "wfi" ...
 
Status
Not open for further replies.
Back
Top