Verifying crystal circuits, oscillator specifications, and clock distribution for reliable operation
Crystals require specific load capacitance to oscillate at their rated frequency. This load capacitance (CL, specified on the crystal datasheet, typically 8pF-20pF) must be provided by external capacitors on the oscillator input (XI/OSC_IN) and output (XO/OSC_OUT) pins. The external capacitor values must be calculated considering pin capacitance and PCB stray capacitance to achieve the exact CL specified by the crystal manufacturer.
Formula: CL = (C1 * C2) / (C1 + C2) + C_stray, where C1 and C2 are the external load capacitors and C_stray includes IC pin capacitance and PCB trace capacitance (typically 2-5pF).
Incorrect load capacitance causes the crystal to oscillate at the wrong frequency. Too little capacitance: frequency runs high. Too much capacitance: frequency runs low. For USB (requiring +/-0.25% accuracy), a 50ppm frequency error from wrong load caps can prevent USB enumeration. For UART at high baud rates, even 100ppm error accumulates over a data frame causing bit errors. A 32.768kHz RTC crystal with wrong load caps drifts minutes per day instead of seconds per month.
8MHz crystal for STM32F407:
Crystal: NDK NX3225SA-8.000MHz CL (load capacitance): 8pF (from crystal datasheet) ESR maximum: 80 ohms STM32F407 oscillator: Pin capacitance (from STM32 datasheet): 5pF per pin (C_OSC_IN, C_OSC_OUT) PCB stray: ~2pF (short traces, guard ground) Calculation: CL = (C1 * C2) / (C1 + C2) + C_stray_total For symmetric C1 = C2 = C: CL = C/2 + C_stray 8pF = C/2 + (5pF + 2pF)/2 [Note: pin cap is per pin, stray is total] More accurately per AN2867: CL = (C1 * C2)/(C1 + C2) + C_stray = C1/2 + C_stray 8pF = C1/2 + 3pF (assuming 3pF total stray including pin cap contribution) C1 = C2 = 10pF Selected: 10pF NP0/C0G 0402 capacitors on both OSC_IN and OSC_OUT pins. Verified against ST AN2867 Table 4: 8MHz/8pF CL recommends 10pF caps. MATCH.
Wrong load capacitors: Crystal specifies CL = 20pF. Engineer puts 20pF caps on each pin (C1 = C2 = 20pF). Actual load: 20pF/2 + 3pF(stray) = 13pF (too low!). Crystal runs 25ppm high. For 8MHz HSE used as USB reference (requires +/-0.25% = 2500ppm): 25ppm is within spec. But for 32.768kHz RTC crystal: wrong caps cause 5 seconds/day drift instead of 1 second/month. Alternatively: using 22pF X7R caps that lose 30% capacitance at low temperatures, causing oscillation failure at -20C.
KiCad: Add load capacitor calculation as text note near crystal circuit. Specify NP0/C0G in component value/description field. Reference AN2867 in schematic notes.
Altium: Use component parameters to specify cap type requirement (NP0). Add design note linking to crystal datasheet and load cap calculation.
OrCAD: Place calculation note near crystal. Use component properties to specify dielectric type (NP0/C0G) to ensure correct ordering.
When using a packaged crystal oscillator (as opposed to a bare crystal), the output frequency must be verified against system requirements: PLL multiplication constraints, peripheral clock requirements, USB reference needs, and communication baud rate accuracy. The oscillator frequency, combined with PLL settings, must produce exact target frequencies for all system clocks without fractional errors that cause drift.
Common system frequencies and their required oscillator inputs must be mapped completely before oscillator selection.
Choosing the wrong oscillator frequency can make it impossible to achieve exact baud rates (UART), exact frame rates (display), or USB compliance (48MHz exact for USB Full-Speed). For example, a 12MHz oscillator on STM32F4 cannot produce exactly 48MHz for USB through any PLL configuration. But 8MHz can: 8MHz * 336 / 8 / 7 = 48MHz exactly. Wrong crystal frequency = hardware that cannot be fixed with firmware, requiring crystal replacement and potentially board respin if footprint doesn't match.
STM32F407 with 8MHz HSE crystal:
HSE = 8MHz. PLL configuration: PLLM = 8 (VCO input = 8MHz/8 = 1MHz) PLLN = 336 (VCO output = 1MHz * 336 = 336MHz) PLLP = 2 (System clock = 336MHz/2 = 168MHz) -- CPU clock PLLQ = 7 (USB clock = 336MHz/7 = 48.000MHz EXACTLY) -- USB requirement met UART1 at 115200 baud from 84MHz APB2 clock: BRR = 84MHz / (16 * 115200) = 45.57 --> rounds to 45.5625 Actual baud = 84MHz / (16 * 45.5625) = 115274 baud Error: (115274 - 115200) / 115200 = 0.064% -- well within 2% limit All clocks achievable with 8MHz crystal. USB exact. UART error minimal.
10MHz crystal - USB failure: Designer chooses 10MHz crystal (common in lab equipment). PLL attempts to generate 48MHz: 10MHz * N / M = 48MHz. Options: 10*48/10 = 48 (PLLQ must divide VCO, VCO must be 96-432MHz range). VCO = 10*48 = 480MHz (exceeds 432MHz max). Try: VCO = 10*24 = 240MHz, PLLQ = 5: 240/5 = 48MHz. But PLLM = 10, VCO_in = 1MHz, PLLN = 240: VCO = 240MHz. PLLP = 240/168 = 1.43 (not integer!). Cannot achieve both 168MHz CPU AND 48MHz USB with 10MHz crystal. Must choose between full-speed CPU or USB functionality.
KiCad: Document PLL configuration on schematic near clock circuit. Show clock tree diagram with all derived frequencies and their targets.
Altium: Use schematic text to document clock tree. Link to STM32CubeMX or vendor clock configuration tool output.
OrCAD: Add clock tree documentation as a schematic text block or separate reference sheet showing all PLL divisors and resulting frequencies.
Clock distribution fan-out addresses how a single clock source is distributed to multiple destination ICs. Each clock input presents a capacitive load, and the driving source must have sufficient output drive strength to maintain signal integrity across all loads. When a single oscillator must clock multiple devices, a dedicated clock buffer/distributor IC may be needed to maintain signal quality (clean edges, low jitter) at each destination.
Fan-out is limited by: driver output current capability, total capacitive load (slows edges), and stub lengths creating reflections.
Overloading a clock output with too many destinations causes slow rise/fall times, reduced voltage swing, and increased jitter. A 25MHz oscillator driving 5 Ethernet PHYs may have insufficient drive strength, resulting in the farthest PHY seeing degraded clock edges with duty cycle distortion. This causes bit errors on Ethernet that appear random. Alternatively, long clock traces with multiple stubs create impedance discontinuities that generate reflections, adding timing uncertainty (jitter) to the clock.
25MHz clock distribution for dual Ethernet PHY:
Source: SiT8008BI 25MHz oscillator (LVCMOS output, 8mA drive)
Destinations: 2x KSZ8081RNA Ethernet PHY (XI input, 5pF each)
Analysis:
Total capacitive load: 2 * 5pF + 5pF(trace) = 15pF
Rise time: 2.2 * (50 ohm output) * 15pF = 1.65ns
Required: 25MHz clock period = 40ns. Rise time is 4% of period -- ACCEPTABLE.
Drive capability: 8mA into 15pF at 25MHz: I = C*dV/dt = 15pF*3.3V/1.65ns = 30mA...
CONCERN: Peak current exceeds 8mA rating!
SOLUTION: Add CDCLVD1208 clock buffer (8-output, 24mA drive per output)
Oscillator -> Buffer -> PHY1 (dedicated output)
-> PHY2 (dedicated output)
Each PHY gets its own driven clock with clean edges. Jitter: < 30ps additive.
Single oscillator overloaded: One 25MHz CMOS oscillator (4mA drive) connected to: 2 Ethernet PHYs, 1 FPGA reference clock, and 1 clock recovery IC. Total capacitive load: 4 * 5pF + 15pF (traces) = 35pF. Rise time: 2.2 * 50 * 35pF = 3.85ns. Voltage swing reduced because driver current-limits before reaching full 3.3V. FPGA misses clock edges, Ethernet has 0.1% bit error rate. All because the oscillator cannot drive 4 loads simultaneously.
KiCad: Use net highlighting to identify all ICs connected to each clock net. Count loads and verify driver capability. Add clock buffer IC if needed.
Altium: Signal Integrity analysis with IBIS models shows clock quality at each receiver. Net length report identifies clock routing distances.
OrCAD: Generate connectivity report for clock nets. Cross-reference driver output spec against total capacitive load. Simulate with PSpice for critical clocks.
Jitter is the time-domain variation of clock edges from their ideal positions. Phase noise is the frequency-domain representation of the same phenomenon. Different applications have vastly different jitter requirements: USB 2.0 allows +/-500ps, Gigabit Ethernet requires < 1.4ns peak-to-peak, and high-speed SerDes (PCIe, USB 3.0) require < 10-50ps RMS. The oscillator, PLL, and clock distribution must all be designed to meet the jitter budget at the final clock destination.
Jitter budget: Total_jitter = sqrt(jitter_osc^2 + jitter_PLL^2 + jitter_buffer^2 + jitter_power_noise^2).
Clock jitter directly consumes timing margin. In a memory interface with 1.25ns timing window (DDR3-1600), if jitter is 200ps peak-to-peak, that is 16% of the window consumed by jitter alone - before accounting for setup time, hold time, and skew. Excessive jitter causes bit errors in SerDes links (PCIe drops to lower speed), ADC performance degradation (jitter-limited SNR), and communication failures. In audio applications, 1ns of clock jitter creates audible distortion in 24-bit converters.
PCIe Gen3 reference clock jitter budget:
Requirement: PCIe Gen3 reference clock jitter < 3ps RMS (1MHz-10MHz integration) Oscillator: SiT9121AI-1B3 (100MHz, PCIe Gen3 compliant) Phase noise: -140 dBc/Hz at 1MHz offset RMS jitter (1MHz-10MHz): 0.5ps RMS PLL additive jitter: ~1.5ps RMS (from FPGA GTP transceiver specs) Power supply induced: ~0.5ps (with proper decoupling and LC filtering on PLL supply) Clock buffer: ~0.3ps (CDCLVD1208, low-jitter grade) Total: sqrt(0.5^2 + 1.5^2 + 0.5^2 + 0.3^2) = 1.7ps RMS Budget: 3ps RMS available, 1.7ps used. Margin: 43%. PASS. Note: Using standard oscillator (10ps RMS) would exceed budget by 3x.
Standard oscillator for SerDes: Designer uses generic CMOS oscillator ($0.50) with 50ps RMS jitter as PCIe Gen3 reference clock (requirement: < 3ps RMS). PCIe link trains at Gen1 (2.5 GT/s) but fails to negotiate Gen3 (8 GT/s) because the reference clock jitter exceeds the receiver's jitter tolerance. System operates at 1/4 expected bandwidth. Replacing the $0.50 oscillator with a $3.00 PCIe-grade oscillator fixes the issue - but requires board respin if footprint is incompatible.
KiCad: Document jitter requirements and oscillator specs in schematic notes. Specify exact oscillator part number (not generic "25MHz OSC").
Altium: Include jitter specifications in component parameters. Use SI analysis for clock distribution jitter estimation.
OrCAD: Specify oscillator MPN with jitter rating. Document jitter budget calculation on schematic or in referenced design document.
Crystal and oscillator circuits require PCB layout protection from noise coupling. Guard traces (grounded traces surrounding clock signals) and ground pour (copper fill connected to ground around the oscillator area) provide electromagnetic shielding that prevents digital noise from coupling into the sensitive oscillator circuit. This is primarily a layout concern but must be planned at the schematic level through proper grounding and placement documentation.
The clock circuit's susceptibility to coupled noise directly impacts clock jitter and frequency stability.
Crystal oscillator circuits have very high impedance nodes (the crystal itself has impedance in the tens of kilohms during operation). Even small amounts of coupled noise (millivolts) can perturb the oscillation, causing jitter and in extreme cases, oscillation failure. A high-speed digital trace routed near a 32.768kHz RTC crystal can inject enough noise to stop the crystal oscillating entirely (too much noise forces the IC's oscillator amplifier into saturation). Guard traces and ground pour reduce coupling by 20-40dB.
Schematic documentation for crystal layout:
Notes on schematic near crystal circuit: "LAYOUT CRITICAL: Crystal Y1 placement requirements: 1. Place within 3mm of STM32 OSC_IN/OSC_OUT pins 2. Keep crystal traces (XI, XO) under 5mm total length 3. NO other signal traces within 2mm of crystal traces 4. Ground pour completely surrounding crystal area (all layers) 5. No vias under crystal body 6. Load capacitors C3, C4 placed between crystal and MCU 7. Feedback resistor R1 across crystal (not bridging to other nets)" Grounding: Crystal ground caps connect directly to nearest ground plane via (dedicated via, not shared with digital IC ground).
No layout guidance: Crystal placed on schematic with no placement notes. Layout engineer places crystal 25mm from MCU because "it fit there nicely." SPI bus traces at 20MHz route directly under the crystal. 32.768kHz RTC crystal picks up SPI clock harmonics - oscillation becomes unstable, MCU fails to start occasionally (cold start issue when crystal amplitude is low). RTC gains 30 seconds per day from frequency pulling caused by coupled noise.
KiCad: Use text annotations on schematic for layout constraints. In PCB editor: use Rule Areas to define keepout zones around crystals. Copper zone pour around oscillator area.
Altium: Define Room with specific clearance rules. Use keepout regions on signal layers around crystal. Add polygon pour dedicated to oscillator ground. Component placement rules for maximum distance from MCU.
OrCAD: Add placement constraints in schematic notes. In PCB editor (Allegro): use Route Keepout areas and placement constraints near crystal footprint.
Crystal oscillator startup time is the duration from power application (or oscillator enable) until the oscillation reaches stable amplitude and correct frequency. Startup time depends on crystal Q-factor, load capacitance, oscillator drive level, and temperature. The MCU must be configured to wait for oscillator stabilization before switching to the crystal clock (PLL lock requires stable reference). Typical startup: 1-10ms for MHz crystals, 0.5-2 seconds for 32.768kHz crystals.
The MCU's hardware startup timeout (HSE_STARTUP_TIMEOUT) must exceed the crystal's worst-case startup time.
If the MCU switches to the crystal-based PLL before the oscillation is stable, the PLL may lock onto a wrong frequency or fail to lock entirely. This can cause the MCU to run at an undefined speed, making all timing-critical peripherals (UART, USB, SPI) malfunction. In worst cases, the PLL never locks and the MCU hangs in the clock configuration routine. If the startup timeout is too short and the crystal takes longer (cold temperature, first powerup), the MCU falls back to internal RC oscillator with poor accuracy.
STM32F407 HSE startup configuration:
Crystal: NX3225SA-8.000MHz Startup time: 2ms typical, 5ms maximum (at -40C) Drive level: 100uW maximum STM32F407 configuration: HSE_STARTUP_TIMEOUT = 0x5000 (20,480 clock cycles at 16MHz internal RC) Timeout duration: 20480 / 16MHz = 1.28ms PROBLEM: 1.28ms < 5ms worst case! CORRECTION: Increase to HSE_STARTUP_TIMEOUT = 0x50000 (327,680 cycles) Timeout: 327680 / 16MHz = 20.48ms >> 5ms crystal startup. SAFE. Fallback: If HSE fails to start, firmware detects timeout and continues on HSI (16MHz internal RC). Sets error flag for diagnostics. Does not hang. LSE (32.768kHz) startup: separate configuration with 5-second timeout. RTC initialization waits for LSE ready flag before configuring RTC.
Insufficient startup timeout: MCU configured with default HSE_STARTUP_TIMEOUT of 512 cycles (32us at 16MHz internal). Crystal needs 3ms minimum startup at 25C, 8ms at -40C. At cold startup, crystal is not stable when MCU attempts PLL lock. PLL fails to lock, system clock remains on 16MHz internal RC. USB (requiring exact 48MHz) fails. Firmware developer adds retry loop but timeout is too short - system enters undefined state. Boot time becomes 5 seconds (multiple retries) and occasionally never recovers, requiring power cycle.
KiCad: Document crystal startup time on schematic. Add note with required firmware timeout value. Cross-reference crystal datasheet spec with MCU configuration.
Altium: Include startup time in crystal component parameters. Document MCU configuration requirements in schematic text near clock circuit.
OrCAD: Annotate crystal startup time on schematic. Link to firmware clock initialization requirements in design documentation.