🛠 Overclocker le RP2040 à 200 MHz (et au-delà) en toute connaissance

Objectives

The RP2040 datasheet lists a nominal frequency of 133 MHz, but the datasheet documents an extended mode: up to 200 MHz by over-volting the core to 1.15 V via the over_vrange bit in the VREG (RP2040 datasheet, §2.15.3 Overclocking; publicly confirmed by Raspberry Pi, see also the documentation discussion pico-feedback#499). The chip even features an auto-tuned ROSC that adapts the internal voltage to the silicon (§2.15.2). This tutorial covers how to cleanly reach 200 MHz, prove it with a benchmark, and understand the limitations (QSPI flash, thermal constraints, variability).

Hardware

• 1 × generic RP2040 board (clones with low-quality regulators heat up more: start with a known board, such as Waveshare or Adafruit)
• Pico SDK (C), target linked with pico_stdlib hardware_vreg hardware_clocks
• Optional: modest cooling (heatsink, airflow) for tests above 200 MHz

Complete Code

// oc200.c — 200 MHz avec VREG forcé, benchmark Dhrystone-like
#include "pico/stdlib.h"
#include "hardware/vreg.h"
#include "hardware/clocks.h"

int main(void) {
    stdio_init_all;
    // 1) monter la tension du cœur AVANT la fréquence (datasheet 2.15.3)
    vreg_set_voltage(VREG_VOLTAGE_1_20);   // 1,20 V > nominal 1,10 V
    sleep_ms(10);                          // laisser le régulateur stabiliser
    // 2) demander 200 MHz au PLL (le SDK rebascule sur XOSC si besoin)
    set_sys_clock_khz(200000, true);
    printf("clk_sys = %lu Hz\n", clock_get_hz(clk_sys));

    // 3) benchmark : boucle dépendante, sans FPU (le M0+ n'en a pas)
    uint32_t t0 = time_us_32;
    volatile uint32_t x = 0;
    for (uint32_t i = 0; i < 1000000; i++) { x = x * 1664525u + 1013904223u; }
    uint32_t dt = time_us_32 - t0;
    printf("1e6 iters en %lu us (x=%lu)\n", dt, x);
    while (true) { sleep_ms(1000); }        // laisse la puce « au ralenti »
}

Expected Verification

clk_sys = 200000000 is displayed, and the benchmark time decreases by approximately 1.6× compared to the run at 125/133 MHz (the exact ratio depends on the code and flash wait states). The chip will sustain 200 MHz on a correct board — this is the certified "over_vrange" frequency from the datasheet. To overcome silicon variability, the SDK offers automatic tuning via ROSC (set_sys_clock_khz + autotune mode used by the sys_clk400 example in pico-extras) — MicroPython also documents overclocking beyond 400 MHz on lucky chips (docs rp2).

Common Errors

• Increasing the frequency before the voltage: the core becomes unstable, leading to random crashes — the VREG → PLL order is mandatory.
• Forgetting that the XOSC must remain the source above 150 MHz: the SDK handles this (set_sys_clock_khz switches clk_ref back), but manual clocking that leaves the ROSC as master at 6.4 MHz will cause everything to fail.
• Neglecting the QSPI flash: at 200 MHz, flash timings (QSPI clock, XIP mode) must follow suit — the SDK automatically reduces the QSPI clock, but custom clocking does not.
• Assuming all clones will hold: regulators and clone quality vary; below 1.2 V or on a dubious clone, 200 MHz may be unstable — test with long loops (the benchmark above runs millions of iterations, LCG errors will be visible).
• Overclocking voids the warranty and is not covered by Raspberry Pi's characterization beyond datasheet values — treat it as tuning.
• Powering via a weak USB hub: at 200 MHz, power consumption increases (order of magnitude: tens of mA more), and a brown-out looks like an overclocking bug.
• Comparing benchmarks without disabling the same peripherals: USB, DMA, and the shared AHB bus skew measurements — establish a method before comparing 133 MHz vs 200 MHz.