A phase-locked loop (PLL) is a feedback control circuit that locks the phase and frequency of an output signal to a reference signal, typically to synthesize a higher or lower frequency from a fixed crystal oscillator. In embedded systems, PLLs are found inside most MCUs and SoCs as the primary means of generating the core clock from a low-frequency crystal reference.
In practice
On the majority of modern MCUs, the internal PLL takes a stable low-frequency source — commonly a crystal or internal RC oscillator in a device-specific input frequency range — and multiplies it to produce a higher core clock. For example, an STM32F4 typically runs its Cortex-M4 core at up to 168 MHz by feeding a 8–25 MHz HSE crystal into a PLL configured with input dividers (M), a VCO multiplier (N), and output dividers (P, Q, R). The nRF52840 and many other BLE SoCs use a fractional-N PLL in the RF synthesizer path to generate the RF carrier; the system clock is derived separately. Startup code or a hardware abstraction layer (HAL) must configure the PLL before switching the system clock source to it; running the PLL unconfigured or switching too early is a common cause of erratic behavior and clock instability at reset.
PLL lock time is a practical concern in low-power designs. After waking from deep sleep, the PLL can take tens to hundreds of microseconds to re-acquire lock before the CPU can run at full speed. Some MCUs (e.g., the MSP430 family) bypass this concern entirely by relying on an internal DCO for the core clock rather than using a PLL at all, allowing near-instant wake-up without a lock-acquisition delay. Others, like STM32 parts in STOP mode, optionally keep a low-speed oscillator running and restart the PLL on wake.
PLL configuration errors are a frequent source of subtle bugs. Common mistakes include setting VCO frequency outside the allowed band (e.g., outside 100–432 MHz on STM32F4), forgetting to update flash wait-states before increasing the clock, or not accounting for USB or peripheral clock requirements that impose constraints on the PLL output dividers. Always cross-check the datasheet's PLL input/output frequency ranges, and verify that dependent peripheral clocks (USB typically requires exactly 48 MHz) are satisfied by the chosen PLL settings.
In RF and mixed-signal systems, PLLs serve a second role as frequency synthesizers for carrier generation, and as clock recovery circuits in high-speed serial links. In these contexts, PLL phase noise, lock range, and settling time become critical specifications rather than afterthoughts.
Frequently asked
What happens if I switch the system clock to the PLL before it has locked?
The CPU will run from an unstable, potentially out-of-spec frequency. On most MCUs, the correct sequence is: configure the PLL, poll the lock-detected status bit (e.g., PLLRDY in STM32 RCC
registers), and only then switch the clock mux to the PLL output. Running before lock can cause undefined behavior, including the
MCU stalling, misclocking, or behaving unpredictably.
Why do I need to change flash wait-states when increasing the CPU clock via the PLL?
Flash memory has a fixed access time. At higher clock frequencies, the CPU can issue a new read before the previous one has completed, producing incorrect data. Most Cortex-M MCUs require you to set the number of flash wait-states (
latency cycles) to match the target frequency before switching to the faster clock. For example, STM32F4 parts running at 3.3 V typically require 5 wait-states at 168 MHz, though the exact requirement depends on the specific device and supply voltage range — always consult the datasheet. Failing to do this is a common and hard-to-diagnose bug.
Can I use the internal RC oscillator as the PLL reference instead of a crystal?
Yes, many MCUs support routing the internal oscillator (e.g., HSI on STM32, HIRC on some PIC32 parts) into the PLL. The trade-off is accuracy and stability: internal RC oscillators are typically accurate to within a few percent after factory trim (the exact figure varies by device), compared to a
crystal which can achieve ppm-level accuracy depending on the part and load
capacitors. For
USB,
CAN, or precision timing applications this is usually insufficient without calibration, but for basic CPU clock multiplication it is often acceptable.
What is a fractional-N PLL, and when does it matter in embedded work?
An integer-N PLL can only multiply the reference frequency by whole numbers, limiting the output frequencies available for a given
crystal. A fractional-N PLL uses a divider that rapidly switches between two integer values, producing an effective non-integer multiplication ratio and thus a much finer frequency resolution. This matters for
RF applications (e.g., generating a precise 2.402 GHz Bluetooth channel from a 32 MHz crystal on the nRF52 series) and for audio sample-rate generation where exact frequencies like 44.1 kHz are required.
How do I choose PLL divider settings to hit a target CPU frequency?
The general formula is: F_out = F_ref / M * N / P (using STM32F4 nomenclature as an example). Start by choosing M to bring the PLL input into the allowed VCO input range (typically 1–2 MHz on STM32F4). Then select N to push the VCO to a frequency in its allowed band (100–432 MHz on STM32F4), and finally choose P (2, 4, 6, or 8) to divide down to your target. Simultaneously check the Q divider output to ensure the 48 MHz
USB clock is satisfied if needed. ST's CubeMX tool, and equivalent tools from other vendors, can automate this search, but understanding the constraints manually helps catch tool errors.
Differentiators vs similar concepts
A PLL is sometimes confused with a simple clock divider or a DLL (delay-locked loop). A clock divider can only produce frequencies that are integer fractions of the input; it cannot multiply. A DLL locks on phase delay rather than frequency, making it faster to lock and immune to certain jitter accumulation issues, but it cannot perform frequency synthesis. PLLs multiply, divide, and synthesize frequencies, at the cost of a VCO whose phase noise contributes to output jitter and a lock-acquisition delay after power-up or wake from sleep.
