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

Objetivos

La ficha técnica del RP2040 anuncia 133 MHz nominales, pero la hoja de datos documenta un modo extendido: hasta 200 MHz sobrealimentando el núcleo a 1,15 V mediante el bit over_vrange del VREG (RP2040 datasheet, §2.15.3 Overclocking; confirmado públicamente por Raspberry Pi, ver también el debate de documentación pico-feedback#499). El chip dispone incluso de un ROSC autoajustado que adapta la tensión interna al silicio (§2.15.2). Este tutorial: subir a 200 MHz correctamente, demostrarlo mediante un benchmark y conocer los límites (flash QSPI, térmica, variabilidad).

Material

• 1 × placa RP2040 genérica (los clones con regulador de gama baja se calientan más: apunta primero a una placa conocida, Waveshare/Adafruit)
• Pico SDK (C), objetivo enlazado con pico_stdlib hardware_vreg hardware_clocks
• Opcional: refrigeración modesta (disipador, flujo de aire) para pruebas > 200 MHz

Código completo

// 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 »
}

Verificación esperada

Se muestra clk_sys = 200000000, y el tiempo del benchmark baja aproximadamente 1,6× en comparación con la ejecución a 125/133 MHz (la relación exacta depende del código y de la espera de la flash). El chip aguantará a 200 MHz en una placa correcta — es la frecuencia certificada « over_vrange » de la hoja de datos. Para librarte de la variabilidad del silicio, el SDK ofrece el ajuste automático por ROSC (set_sys_clock_khz + modo autotune utilizado por el ejemplo sys_clk400 de pico-extras) — MicroPython documenta además superaciones por encima de 400 MHz en chips afortunados (docs rp2).

Errores frecuentes

• Subir la frecuencia antes que la tensión: el núcleo se vuelve inestable, fallos aleatorios — el orden VREG → PLL es contractual.
• Olvidar que el XOSC debe seguir siendo la fuente por encima de 150 MHz: el SDK lo gestiona (set_sys_clock_khz vuelve a cambiar clk_ref), pero un reloj manual que deja el ROSC a 6,4 MHz como maestro lo rompe todo.
• Descuidar la flash QSPI: a 200 MHz, los tiempos de espera de la flash (reloj de la QSPI, modo XIP) deben seguir — el SDK reduce el reloj QSPI automáticamente, un reloj propio no.
• Creer que todos los clones aguantan: los reguladores y la calidad de los clones varían; por debajo de 1,2 V o en un clon dudoso, 200 MHz puede ser inestable — prueba con bucles largos (el benchmark anterior ejecuta millones de iteraciones, los errores LCG se ven).
• La overclocking anula la garantía y no está cubierto por el caracterizado de Raspberry Pi más allá de los valores de la hoja de datos — considéralo como tuning.
• Alimentar mediante un hub USB débil: a 200 MHz el consumo sube (órdenes de magnitud: decenas de mA más), un brown-out parece un bug de overclocking.
• Comparar benchmarks sin desactivar los mismos periféricos: el USB, el DMA y el bus AHB compartido distorsionan las mediciones — fija un método antes de comparar 133 vs 200 MHz.