Overclocking Pico with up to 436MHz works

[HermannSW]

First quoting Pico FAQ on overclocking:
viewtopic.php?f=144&t=299523

Can I overclock?

The maximum clk_sys clock speed is 133MHz at normal core voltage (1.1V ±10%), but it can be overclocked. However, this requires more power and a higher core voltage, and may affect the life expectancy of your device. No warranties are given when running outside of the limits specified in the datasheet.

I used program q32.c for years to compare single core integer performance of different microcontrollers and CPUs. A week ago I adapted it to the Pico and found that Pico was faster than all Arduinos tested, but slower than the ESP8266:
viewtopic.php?f=145&t=300265&p=1804700#p1804700


Today I evaluated the Pico overclocking options using "set_sys_clock_khz(_, true)".

First there are frequencies (high and "low") that make /dev/ttyACM0 missing (after flashing the Pico):

Code: Select all

  //set_sys_clock_khz(275000, true); //  /dev/ttyACM0  missing
  //set_sys_clock_khz(124400, true); //  /dev/ttyACM0  missing

Then I tried to identify at which frequency the Pico runs when not explicitely setting sys_clock. To my surprise it was not the often read 133MHz but 130MHz:

Code: Select all

  // 330us
  //set_sys_clock_khz(124000, true); // 346us
  //set_sys_clock_khz(126000, true); // 340us
  //set_sys_clock_khz(128000, true); // 335us
  //set_sys_clock_khz(130000, true); // 330us
  //set_sys_clock_khz(131000, true); // 328us

Then I wanted to see whether "set_sys_clock_48mhz()" does what it states -- and it does not, it sets 50MHz

Code: Select all

  //set_sys_clock_48mhz(); // 894us
  //set_sys_clock_khz(48000, true); // 932us
  //set_sys_clock_khz(50000, true); // 894us

Finally I went higher and higher, and the maximal frequency I was able to run q32.pico.c was 270MHz(!).

Code: Select all

  //set_sys_clock_khz(200000, true); // 214us
  //set_sys_clock_khz(250000, true); // 171us
  //set_sys_clock_khz(266000, true); // 161us  (1596/6)
  //set_sys_clock_khz(270000, true); // 158us

Code: Select all

Press CTRL-A Z for help on special keys                
                                                       
                                                       
158us                                                  
 47| 29|101|                                           
113| 59|  5|
 17| 89| 71|

This is q32.pico.c:
https://gist.github.com/Hermann-SW/6772 ... 543d9d3dbe
Today's commit added printf() of measured time before printing the minimal distinct primes 3x3 magic square. There is a small bug in pico/stdlib(?) that does not always print the last line with the measured time taken into minicom over USB. That happens for high as well as low cpu clocks.


I have not used project generator up to now, I hijacked pico-examples usb hello_world.c and just copied over my code. I don't know the correct way of doing "-O3" compilations, I appended "-O3" just after 1st "$(C_FLAGS)" to
/home/pi/pico/pico-examples/build/hello_world/usbCMakeFiles/hello_usb.dir/build.make


Comparison with ESPs:
80MHz ESP8266 took 304us.
160MHz ESP32 took 149us.
Pico at default 130MHz took 357us.
Pico at maximal 270MHz took 158us.

So Pico (overclocked with 270MHz) is only slightly slower in running q32.pico.c than ESP32.


Other measured microcontrollers and CPUs:
viewtopic.php?f=63&t=208778&p=1804701#p1804701



P.S:

pico.delta2average.png

pico.delta2average.png (9.57 KiB) Viewed 27362 times

[HermannSW]

As expected, Pico clock [MHz] vs. (1/runtime) [Hz] for all measured values in 48..270 MHz range looks linear:

pico_clock_vs_runtime_reciprocal.png

pico_clock_vs_runtime_reciprocal.png (19.03 KiB) Viewed 27305 times

[jamesh]

So what happened when you went over 270?

[davidcoton]

So what happened when you went over 270?

End of the World?
(In which case, OP didn't try.)

[HermannSW]

So what happened when you went over 270?

After flashing, the device /dev/ttyACM0 was missing, nothing to connect minicom to.

I assume that is correct behavior because of calling "set_sys_clock_khz(_, true)".
With required=true assertion there seems to be no /dev/ttyACM0:
https://datasheets.raspberrypi.org/pico ... f#page=196

Parameters
•freq_khz Requested frequency
•required if true then this function will assert if the frequency is not attainable.

End of the World?
(In which case, OP didn't try.)

I did try many values, slightly and far above 270000KHz, but those all seem to have asserted.
As stated in original post, also small frequencies can result in that, here 124400KHz:

Code: Select all

  //set_sys_clock_khz(275000, true); //  /dev/ttyACM0  missing
  //set_sys_clock_khz(124400, true); //  /dev/ttyACM0  missing

[cleverca22]

After flashing, the device /dev/ttyACM0 was missing, nothing to connect minicom to.

try adding in both blink and hw uart, so you can see if its still alive, and then debug why the usb died

[HermannSW]

After flashing, the device /dev/ttyACM0 was missing, nothing to connect minicom to.

try adding in both blink and hw uart, so you can see if its still alive, and then debug why the usb died

I will do in my evening, did not use uart until now because usb was so convenient ...

[cleverca22]

did not use uart until now because usb was so convenient ...

same, i still need to confirm what pins the hw uart is even on, the usb-uart just saves having to find a usb adapter

[HermannSW]

same, i still need to confirm what pins the hw uart is even on, the usb-uart just saves having to find a usb adapter

Back in the mid 80s while studying CS, I worked in a special purpose machinery manufacture in parallel, and wrote more or less a "plotter" program (no pen, instead a 4000bar water-jet coming out of 0.1mm diameter hole in industrial diamond). I had no idea how to drive the stepper motors, so did just use parallel port of 8088 office PC for bidirectional signals

[kilograham]

about about 270Mhz system clock you are probably out of range of the flash chip.

Do something like this in your CMakeLists.txt

Code: Select all

pico_define_boot_stage2(slower_boot2 ${PICO_DEFAULT_BOOT_STAGE2_FILE})
target_compile_definitions(slower_boot2 PRIVATE PICO_FLASH_SPI_CLKDIV=4)

pico_set_boot_stage2(TARGET slower_boot2)

to use a custom boot_stage2 which configures the flash slower (relative to system clock)

[kilograham]

p.s. i recommend you move to SDK 1.0.1 which fixes a bug in the dependency checking of boot stage 2 during build

[HermannSW]

Did run into issues with SWD (doc not correct wrt. example
viewtopic.php?f=145&t=302206
SWD single stepping does work, but cannot see USB output).

I created pico/buildu directory and did cmake normal non-SWD environment there.
Flashing blink.uf2 does blink, flashing with added "set_sys_clock_khz(270000, true)" does blink, but flashing with 275000 does not blink after flashing, so assertion does not continue into endless while blink loop:

Code: Select all

...
    gpio_set_dir(LED_PIN, GPIO_OUT);
    set_sys_clock_khz(275000, true);
    while (true) {
...

This test was done after upgrading to 1.0.1 SDK, but without kilograham's CMakeLists.txt change.

[HermannSW]

about about 270Mhz system clock you are probably out of range of the flash chip.

Do something like this in your CMakeLists.txt

Code: Select all

pico_define_boot_stage2(slower_boot2 ${PICO_DEFAULT_BOOT_STAGE2_FILE})
target_compile_definitions(slower_boot2 PRIVATE PICO_FLASH_SPI_CLKDIV=4)

pico_set_boot_stage2(TARGET slower_boot2)

to use a custom boot_stage2 which configures the flash slower (relative to system clock)

Thanks, I tried that.

This is the diff:

Code: Select all

pi@raspberrypi400:~/pico/pico-examples/buildu/blink $ git diff ../../blink/CMakeLists.txt 
diff --git a/blink/CMakeLists.txt b/blink/CMakeLists.txt
index 1bf1d2a..682c8cd 100644
--- a/blink/CMakeLists.txt
+++ b/blink/CMakeLists.txt
@@ -10,3 +10,9 @@ pico_add_extra_outputs(blink)
 
 # add url via pico_set_program_url
 example_auto_set_url(blink)
+
+# https://www.raspberrypi.org/forums/viewtopic.php?f=145&t=301902&p=1811687#p1811232
+pico_define_boot_stage2(slower_boot2 ${PICO_DEFAULT_BOOT_STAGE2_FILE})
+target_compile_definitions(slower_boot2 PRIVATE PICO_FLASH_SPI_CLKDIV=4)
+
+pico_set_boot_stage2(blink slower_boot2)
pi@raspberrypi400:~/pico/pico-examples/buildu/blink $ 

After making, Pico blinks for "set_sys_clock_khz(270000, true)", but does not blink for "set_sys_clock_khz(275000, true)" added. So the change did not help, or 270MHz is really the top.

6*266MHz is 1596MHZ, so I tried 1596MHZ/4=399MHz as well, no blinking after flashing.

Finally I did set to 124400 which should not have any speed issues, no blinking as reported originally for /dev/ttyACM0 missing.

[WestfW]

Are you still running your code from the QSPI flash?
Have you tried compiling it to run from RAM?

[kilograham]

note the "true" argument to set_sys_clock_khz means assert if you can't get the frequency exactly (which you may not see evidence of at this point other than a hang)

if you pass false, it will return a return code.

of course you might have max-ed out your pico at 1.1v you can (at your own risk) do say

Code: Select all

vreg_set_voltage(VREG_VOLTAGE_1_25);

or similar first

[HermannSW]

Are you still running your code from the QSPI flash?
Have you tried compiling it to run from RAM?

Yes, and not until now.

What I did is to remove the previously added stuff to pico/pico-examples/blink/CMakeLists.txt.
Then I did "set_sys_clock_khz(270000, true)" before the while loop, did make and copied blink.uf2.
That way I got blinking led on Pico.

Next I added this line at bottom of pico/pico-examples/blink/CMakeLists.txt to force RAM execution:
https://datasheets.raspberrypi.org/pico ... f#page=266

Code: Select all

pico_set_binary_type(blink no_flash)

And I increased clock from 270000 to 275000.
Again did make, copied blink.uf2 after reconnecting with bootsel key pressed.
result is no blinking, so execution from RAM did not help to get faster clock than 270MHz.
Finally I disconnected USB cable, and reconnected to verify that the 275000 code was executed in RAM.
And really the Pico was blinking again from the 270000 blink.uf2 that was still on the flash.

[HermannSW]

of course you might have max-ed out your pico at 1.1v you can (at your own risk) do say

Code: Select all

vreg_set_voltage(VREG_VOLTAGE_1_25);

or similar first

Thanks for that pointer, I will try, found that function:
https://datasheets.raspberrypi.org/pico ... f#page=187

Found the enumeration in pico/pico-sdk/src/rp2_common/hardware_vreg/include/hardware/vreg.h:

Code: Select all

enum vreg_voltage {
    VREG_VOLTAGE_0_85 = 0b0110,    ///< 0.85v
    VREG_VOLTAGE_0_90 = 0b0111,    ///< 0.90v
    VREG_VOLTAGE_0_95 = 0b1000,    ///< 0.95v
    VREG_VOLTAGE_1_00 = 0b1001,    ///< 1.00v
    VREG_VOLTAGE_1_05 = 0b1010,    ///< 1.05v
    VREG_VOLTAGE_1_10 = 0b1011,    ///< 1.10v
    VREG_VOLTAGE_1_15 = 0b1100,    ///< 1.15v
    VREG_VOLTAGE_1_20 = 0b1101,    ///< 1.20v
    VREG_VOLTAGE_1_25 = 0b1110,    ///< 1.25v
    VREG_VOLTAGE_1_30 = 0b1111,    ///< 1.30v

    VREG_VOLTAGE_MIN = VREG_VOLTAGE_0_85,      ///< Always the minimum possible voltage
    VREG_VOLTAGE_DEFAULT = VREG_VOLTAGE_1_10,  ///< Default voltage on power up.
    VREG_VOLTAGE_MAX = VREG_VOLTAGE_1_30,      ///< Always the maximum possible voltage
};

I assume the idea is not to increase Pico sales by making me burn my Pico (I do have 3, will try in small incremental steps starting with 1.15V).

[HermannSW]

I just kept the run from RAM setup, so that after disconnecting USB cable and reconnecting the safe 270MHz with default 1.1V blink.uf2 will run.

I tested in 0.05V steps starting with 1.15V and ended with maximal value of 1.30V.
To be sure that voltage has been switched, code did sleep for a second before touching clock.
Even after flashing blink.uf2 with 1.3V, Pico did not blink.
After removing USB cable and reconnecting Pico blinked again (code from flash, at 270MHz):

Code: Select all

...
    vreg_set_voltage(VREG_VOLTAGE_1_30);
    sleep_ms(1000);
    set_sys_clock_khz(275000, true);
...

Summary of latest experiments:
Neither running code from RAM nor increasing voltage from 1.1V to 1.3V did allow to run blink with 275MHz clock.

[kilograham]

as i say 275Mhz may not be possible (and the ,true is causing an assert)

try 360Mhz which I know works (well assuming your silicon is not on the slow end)

[HermannSW]

as i say 275Mhz may not be possible (and the ,true is causing an assert)

try 360Mhz which I know works (well assuming your silicon is not on the slow end)

@kilograham Thanks for the many breadcrumbs, it really works!

But only running from RAM, from flash even 1.3V do not make it blink.
From RAM 1.15V does not blink, but with 1.2V it blinks happily!.

Code: Select all

pi@raspberrypi400:~/pico/pico-examples/buildu/blink $ tail -1 ../../blink/CMakeLists.txt 
pico_set_binary_type(blink no_flash) 
pi@raspberrypi400:~/pico/pico-examples/buildu/blink $ 

Code: Select all

pi@raspberrypi400:~/pico/pico-examples/buildu/blink $ cat ../../blink/blink.c 
/**
 * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

#include "pico/stdlib.h"
#include "hardware/vreg.h"

int main() {
    const uint LED_PIN = 25;
    gpio_init(LED_PIN);
    gpio_set_dir(LED_PIN, GPIO_OUT);
    vreg_set_voltage(VREG_VOLTAGE_1_20);
    sleep_ms(1000);
    set_sys_clock_khz(360000, true);
    while (true) {
        gpio_put(LED_PIN, 1);
        sleep_ms(250);
        gpio_put(LED_PIN, 0);
        sleep_ms(250);
    }
}
pi@raspberrypi400:~/pico/pico-examples/buildu/blink $ 

I just changed the thread title to 360MHz.

[cleverca22]

i'm thinking you should modify the parts of the sdk around set_sys_clock_khz() to print all of the clock config registers as they are being set, and to fflush() before it puts them into effect

then write up a spreadsheet, showing the final clock, all of the configs, and the min voltage it works at, along with if flash still worked, and the flash divisor

[HermannSW]

@cleverca22 Good idea.

I did want to see a real program running at 360MHz, not only blink.

So I used code that does wait for USB ready, then inputs a number and outputs cube of that number, repeat. That code can be seen below. And I wanted to query which clock frequency. For the set_sys_clock_khz(_, true) we already know that the frequency requested in 1st arg can be set -- otherwise that function asserts and stops program flow. But I found function frequency_count_khz() and passed CLOCKS_FC0_SRC_VALUE_CLK_SYS as argument. For 270MHz the output is as expected in minicom:

Code: Select all

Press CTRL-A Z for help on special keys

tud_cdc_connected()
clk_sys = 270000kHz
7
343

But for 360MHz either the measurement or the printf() seems to have real problems (we know that clock is 360MHz because not having asserted at that output):

Code: Select all

Press CTRL-A Z for help on special keys

tud_cdc_connected()
clk_sys = 36863¡kHz
8
512

Compile to RAM:

Code: Select all

pi@raspberrypi400:~/pico/pico-examples/buildu/hello_world/usb $ tail -1 ../../../hello_world/usb/CMakeLists.txt 
pico_set_binary_type(hello_usb no_flash)
pi@raspberrypi400:~/pico/pico-examples/buildu/hello_world/usb $

Code:

Code: Select all

pi@raspberrypi400:~/pico/pico-examples/buildu/hello_world/usb $ cat ../../../hello_world/usb/hello_usb.c 
#include <stdlib.h>
#include "pico/stdlib.h"
#include <tusb.h>
#include "hardware/vreg.h"
#include "hardware/clocks.h"

#define L 5
unsigned char str[L+1];

unsigned char *readLine() {
  unsigned char u, *p;
  for(p=str, u=getchar(); u!='\r' && p-str<L; u=getchar())  putchar(*p++=u);
  *p = 0;  return str;
}

int main(void) {
  stdio_init_all();

  vreg_set_voltage(VREG_VOLTAGE_1_20);
  sleep_ms(1000);
  set_sys_clock_khz(360000, true);

  while (!tud_cdc_connected()) { sleep_ms(100);  }
  printf("tud_cdc_connected()\n");
  printf("clk_sys = %ukHz\n", frequency_count_khz(CLOCKS_FC0_SRC_VALUE_CLK_SYS));

  for(;;) { int n=atoi(readLine());  printf("\n%d\n",n*n*n); }

  return 0;
}
pi@raspberrypi400:~/pico/pico-examples/buildu/hello_world/usb $ 

With those changes in place just do "make" and copy hello_usb.uf2 to the fake drive. Finally run this and enter numbers in minicom, followed by newline (at most 5 digits):

Code: Select all

$ minicom -b 115200 -o -D /dev/ttyACM0

[kilograham]

ah lightbulb - maybe try blowing away your build directory and re-doing to pick up the "slow" boot stage 2 (at least to be sure) if you aren't using the 1.0.1 sdk which fixes some dependency checking in cmake for the boot stage 2

[HermannSW]

ah lightbulb - maybe try blowing away your build directory and re-doing to pick up the "slow" boot stage 2 (at least to be sure) if you aren't using the 1.0.1 sdk which fixes some dependency checking in cmake for the boot stage 2

I was on 1.0.1 already, did throw away my build directory and created again. No change, the 360000 number gets sent to output scrambled.


From further above in this thread, on running q32.pico.c for computing minimal distinct primes 3x3 magic square:

Comparison with ESPs:
80MHz ESP8266 took 304us.
160MHz ESP32 took 149us.
Pico at default 130MHz took 357us.
Pico at maximal 270MHz took 158us.

So Pico (overclocked with 270MHz) is only slightly slower in running q32.pico.c than ESP32.

I just tried running with 360MHz, and now Pico completely outperforns the ESP32 with only 96us taken! Yes, I/O seems to have problem, middle bottom number should read as 89, all other numbers are correct:

Code: Select all

Press CTRL-A Z for help on special keys                         
                                                                
                                                                
                                                                
96us                                                            
 47| 29|101|
113| 59|  5|
 17| 8`| 71|

96us

Next smaller runtime from the table is 30us from Pi0 ...
https://stamm-wilbrandt.de/en/forum/mc.performance.png

[HermannSW]

I tried to slow down the clock before doing printf() showing the 3x3 magic square, that did not work (I saw no output in minicom at all).

Next I increased from 1.2V further to maximum of 1.3V.
Before 266MHz worked, and that was 1596MHz/6.
Now I tried 1596MHz/4=399MHz.
Proportional faster, but now really I/O is not reliable anymore, just stops in middle of 3x3 square output:

Code: Select all

Press CTRL-A Z for help on special keys


87us
 47| 29|101|

I need to get setting clock slower (to 130MHz default) working before doing printf() output.