Dynamic Clock Speed of Teensy 4.0

[wdmerges]

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

[defragster]

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.

[wdmerges]

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.

[jonr]

What was the conclusion on this? Is there an easy way to jump to 912 Mhz for a brief period?

[Frank B]

What was the conclusion on this? Is there an easy way to jump to 912 Mhz for a brief period?

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.

[jonr]

Unfortunately, it creates audio glitches if one switches back and forth.

[Frank B]

Audio uses its own PLL.. hm. interesting... wonder what the reason for the glitches is.

[defragster]

Don't see set_arm_clock() disabling interrupts - but clock and voltage changes might cause chip interruption/stall to DMA or other timing/processing?

[Frank B]

Sounds reasonable. The bus clock changes.

[jonr]

A clue: my DAC sees an interruption in toslink output. Perhaps the audio PLLs get reset?

[DD4WH]

@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.

[jonr]

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.

[Frank B]

Which SPDIF output do you use?

[Frank B]

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.

[Frank B]

Ok, I tried this:

#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.

[DD4WH]

@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.

[Frank B]

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...

[jonr]

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.

[Frank B]

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..

[mjs513]

@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.

[Frank B]

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...

[defragster]

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:

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)

[Frank B]

It switches off, i think that's the best to prevent further heating.
Nobody knows wether it crashes again, so.. just switch off.

[defragster]

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 ...

[Frank B]

Yes, it prints a message, and switches off after that