Clocks, Reset, and Execution

Every register, counter and state machine in the chip changes state on clock edges. A clock of frequency $f$ has period $T = 1/f$: 125 MHz is 8 ns per cycle, 12 MHz is 83.3 ns. Lesson 2’s timing formula, $t = N \times \text{CPI} / f$, is only as good as your knowledge of $f$, and $f$ is set by firmware.

Microcontrollers offer several clock sources:

• Internal RC oscillator. On-chip, starts almost instantly, needs no external parts, but its frequency typically varies noticeably with temperature, supply voltage and from chip to chip.
• Crystal oscillator. Uses an external quartz crystal; accurate to within a small fraction of a percent, but takes longer to start (often milliseconds).
• PLL (phase-locked loop). Multiplies a reference up to a high frequency, then divides it down: $f_{\text{out}} = f_{\text{ref}} \times N / (M \times P)$.

The RP2040 SDK’s default plan is a worked instance of all three ideas: a 12 MHz crystal feeds the system PLL, which multiplies by 125 to a 1500 MHz internal oscillator and divides by 6 and then 2:

$$f_{\text{sys}} = \frac{12\ \text{MHz} \times 125}{1 \times 6 \times 2} = 125\ \text{MHz}$$

The SDK sets this up in its runtime initialisation, after reset and before main(). Until then the chip runs from whatever clock it resets to, often an internal oscillator slower than the final clock. That explains the delay in the opening: a loop calibrated for 125 MHz that runs before the clocks are configured, on a start-up clock of, say, 12 MHz, takes $125/12 \approx 10.4$ times longer. Any busy-wait simply scales with the frequency it actually runs at. Unit 8 builds the full clock tree; the lesson here is that the clock frequency is part of the program’s state, not a constant.

A clock edge every 8 ns does not make flash faster. A flash read takes a fixed access time set by the memory technology; if that is longer than one clock period, the flash controller holds the core with wait states (lesson 3’s wait signal) until the data is valid. In the simplest model,

$$W = \left\lceil t_{\text{acc}} \cdot f \right\rceil - 1$$

wait states per access, so each fetch takes $W + 1$ cycles.

↑ This step uses the figure at the top of the page.

Real parts publish a table of required wait states against clock frequency and supply voltage, and firmware must program the flash controller for the right number before raising the clock; raising the clock first means reading flash too early and executing garbage. The penalty is hidden, most of the time, by prefetch buffers that read ahead along straight-line code and by caches that keep recently used instructions. The RP2040 reads its external flash through such a cache, which is why its address map has separate cached and uncached flash windows.

On a Cortex-M processor the first thing the core does after reset is read the vector table, a table of 32-bit words at a known address (address 0 on reset for Armv6-M):

1. Word 0 is loaded into SP: the initial stack pointer.
2. Word 1 is loaded into PC: the address of the reset handler. Its lowest bit must be 1, marking Thumb code; the core clears it when it sets the PC and records Thumb state in the xPSR’s T bit.
3. The reset handler, part of the startup code, sets up the C environment: copy .data from flash to RAM, zero .bss, initialise clocks and other hardware, and finally call main().

The RP2040 SDK’s crt0.S shows exactly this shape: its vector table begins .word __StackTop, .word _reset_handler, and the handler copies data, clears .bss, calls runtime_init and then main. (On the RP2040 the core first runs the boot ROM mapped at address 0, which finds the program in flash and hands over to this vector table; unit 5 follows that path.) No C code that relies on initialised or zeroed static variables may run until .data and .bss are set up, which is why the first part of startup code is written in assembly or in very careful C. (Some startup files call a C function such as CMSIS’s SystemInit() to configure clocks even before that; such functions must not use static data.)

A loop executes 4 instructions per iteration for 1 000 000 iterations directly from flash with a 40 ns access time. Assume one cycle per instruction plus flash wait states, and, to expose the effect, no cache or prefetch.

At 24 MHz: $T = 41.7$ ns, longer than 40 ns, so $W = \lceil 40 \times 0.024 \rceil - 1 = 0$. Each instruction takes 1 cycle: $4 \times 10^6$ cycles $/ 24\ \text{MHz} = 167$ ms.

At 125 MHz: $T = 8$ ns, $W = \lceil 40 \times 0.125 \rceil - 1 = 4$, so each fetch takes 5 cycles: $2 \times 10^7$ cycles $/ 125\ \text{MHz} = 160$ ms.

The clock went up 5.2 times and the loop got 4 % faster. With the loop held in a cache (or copied to SRAM, which the RP2040 SDK supports through its “not in flash” function attributes), every fetch takes one cycle and the same loop takes $4 \times 10^6 / 125\ \text{MHz} = 32$ ms. The model is deliberately crude; real cores fetch 32 or more bits at a time and prefetch ahead. But it is why datasheets give wait-state tables, why chips have caches, and why the only trustworthy timing is a measurement (unit 6) or a hardware timer (unit 8).