123 Main Street, New York, NY 10001

Submit Your BOM

RTC (Real-Time Clock): 32.768 kHz Timebase, Alarms & Timestamps

RTC (Real-Time Clock): 32.768 kHz Timebase, Alarms & Timestamps

← Back to:Reference Oscillators & Timing

RTC is a low-power 32.768 kHz timebase + calendar/alarms/timestamp block that must be budgeted, validated, and kept leak-free to stay accurate for years. This page turns “RTC accuracy and battery life” into a repeatable engineering workflow: design → bring-up → production calibration → field monitoring.

What an RTC is — and what it is not (Scope & boundary)

An RTC (Real-Time Clock) is a low-frequency timebase (typically 32.768 kHz) plus calendar/alarms and timestamp capture. Engineering success is judged by four outcomes: accuracy (seconds/day), power (VBAT-domain current), reliability (start/hold behavior across temperature and contamination), and verifiability (tests that prove those claims on real boards).

Typical outputs (what systems consume)
  • Seconds tick (1 Hz) and steady timekeeping cadence
  • Calendar time (Y/M/D/h/m/s) for logs and schedules
  • Alarm interrupt (wake/schedule) with status flags
  • Timestamp register (event time capture) for traceability
Common entry questions (search intent → page value)
  • “Is an RTC needed?” Decide by: power-loss time retention, alarm wake requirements, and timestamp evidence needs.
  • “MCU has an RTC but it is not accurate.” Treat accuracy as a budget: timebase tolerance + temperature drift + aging + board parasitics + calibration residual.
  • “Need calendar/alarms/timestamps.” Focus on atomic read/write, flag behavior, and capture timing—not just register names.
Boundary lock (prevents topic overlap)

This page does not expand into backup-power switchover hardware, tamper/signed-time security, or TCXO disciplining loops. Use the dedicated sibling pages for those topics: RTC Backup & Switchover, Secure RTC / Time-Stamping, TCXO-Based RTC.

Figure 1 — RTC functional boundary map
RTC functional boundary map Block diagram showing 32.768 kHz timebase into divider and counters, feeding calendar, alarms, and timestamp, with I2C/SPI and interrupt interfaces and a VBAT domain, plus accuracy, power, and reliability KPIs. Timebase chain RTC functions System interfaces 32.768 kHz Crystal / XO Divider Prescaler Counters 1 Hz tick Calendar Y/M/D h:m:s Alarms Wake / schedule Timestamp Event capture I²C / SPI Registers INT / IRQ Alarm / status CLKOUT Optional VBAT domain Retention + low power Accuracy Power Reliability

RTC architecture in one page (Block-level mental model)

A robust RTC is best treated as a chain of deterministic blocks. Each block has a small set of knobs (design/configuration choices) and a small set of observable symptoms (test points). This mental model prevents common failure patterns: “it runs in the lab but fails after assembly”, “it keeps time but misses alarms”, and “VBAT current does not match datasheet”.

The time path (what must never lie)

Timebase (32 kHz) → Prescaler → Seconds counter → Calendar (Y/M/D/h/m/s). Accuracy errors originate upstream (timebase + load + temperature + aging), while calendar correctness errors are usually firmware sequencing and atomicity issues.

Core functional blocks (knobs → symptoms)
Timebase
  • Knobs: crystal/XO choice, load strategy, drive/enable modes
  • Symptoms: start/stop across temperature, fixed ppm offset, sensitivity to contamination
Prescaler & counters
  • Knobs: 1 Hz tick routing, update/hold bits (if present)
  • Symptoms: off-by-one reads, jumps after time set, inconsistent “seconds tick” behavior
Alarms
  • Knobs: mask/compare fields, one-shot vs periodic
  • Symptoms: missing alarms, double-fires, IRQ stuck due to flag semantics
Timestamp capture
  • Knobs: trigger source, latch/clear sequence
  • Symptoms: one-second ambiguity, race with reads, event-to-register latency assumptions
Trim / calibration
  • Knobs: ppm trim step, update timing, storage of calibration metadata
  • Symptoms: fixed offset remains, temperature-dependent residual, field drift beyond expectations
Power domains
  • Knobs: retention scope, interface availability on VBAT
  • Symptoms: unexpected VBAT current, loss of registers, flags that reset on VCC loss
Minimal test map (what to prove early)
  • Timebase: confirm 32 kHz presence and stable frequency without probe loading artifacts
  • Accuracy: convert ppm to seconds/day and log across temperature points
  • VBAT current: measure by mode (osc on/off, interface retention on/off, CLKOUT on/off)
  • Alarm & timestamp: validate flag semantics, interrupt behavior, and atomic read sequence
Figure 2 — RTC block diagram with power-domain separation
RTC block diagram with power-domain separation Diagram showing main VCC domain and backup VBAT domain, including 32k oscillator, divider, counters, calendar, alarms, timestamp latch, status flags, trim registers, and cross-domain signals such as interrupt, optional I2C retention, and timestamp trigger. Main domain (VCC) Backup domain (VBAT) I²C / SPI Host access Host logic Reads / clears IRQ handling Alarm / status 32k oscillator Crystal / XO Divider Counters 1 Hz tick Calendar core Alarms Compare / mask Timestamp latch Status / flags Trim / calibration regs INT I²C retain (opt) TS trigger

Timebase options at 32.768 kHz (Crystal vs XO vs internal RC)

Timekeeping accuracy becomes intuitive when expressed as seconds per day. A useful rule of thumb is 1 ppm ≈ 0.0864 s/day. Timebase selection is therefore a trade among accuracy (initial + temperature + aging + parasitics), VBAT current, and bring-up/manufacturing risk.

Executive selection summary (decision entry)
  • Crystal (32.768 kHz): lowest power and lowest BOM cost, but most sensitive to start margin (ESR), board parasitics (CL error), and contamination/leakage.
  • XO / integrated oscillator: fastest bring-up and stable start behavior; typically higher cost and VBAT current. Accuracy is product-dependent (initial tolerance, temperature drift, aging).
  • Internal RC (if available): suitable for “time sense” (relative timing / coarse wake windows), not for “true clock” (calendar-grade time, compliance logging, or long holdover). Expect large temperature and voltage dependence.
Three hard gates (prevents overthinking)
  • Accuracy target: define an allowed s/day error over the required temperature range.
  • VBAT budget: decide whether the backup domain must stay in the low-µA class or can tolerate higher steady current.
  • Manufacturing environment: contamination risk, long routing, connectors, or humidity push the design toward solutions with lower board sensitivity.
Boundary lock (keeps this page focused)

This section does not expand into phase-noise/jitter budgeting (high-speed clocking), disciplining loops (GNSS/network), or backup switchover hardware. Those topics belong to their dedicated pages.

Figure 3 — Timebase options comparison matrix (card-style)
32.768 kHz timebase options comparison matrix Three cards compare Crystal, XO, and Internal RC across accuracy, temperature drift, VBAT current, BOM risk, and bring-up risk. Compare by outcomes (not by labels) Accuracy • Temp drift • VBAT current • BOM risk • Bring-up risk Crystal 32.768 kHz Accuracy High Temp drift Medium VBAT Low BOM risk Medium Bring-up Medium XO Integrated osc Accuracy Medium Temp drift Medium VBAT Higher BOM risk Low Bring-up Low Internal RC Time sense only Accuracy Low Temp drift High VBAT Low BOM risk Low Bring-up Low Use seconds/day targets to choose the timebase; treat BOM and bring-up risk as first-class constraints.

32.768 kHz crystal basics that actually bite (CL/ESR/drive/parasitics)

A 32 kHz crystal node is high-impedance and easily disturbed by board parasitics, leakage, and probe loading. “Correct part number” is not sufficient; robust timekeeping requires controlling CL accuracy, start margin vs ESR, and drive level while preventing contamination-driven leakage paths.

CL errors: how board parasitics translate into seconds/day

The crystal’s specified load capacitance (CL) is the effective capacitance seen by the resonator. External capacitors and board parasitics both contribute. A practical approximation is:

CL ≈ (C1 · C2) / (C1 + C2) + Cstray
Where Cstray includes pad/trace capacitance and input capacitance. Asymmetry between the two pins often creates larger-than-expected frequency pull.
ESR and start margin: why it starts on the bench but fails in production
  • High ESR reduces start margin; cold temperature and contamination often push a marginal design into no-start.
  • Qualification should include temperature corners and “dirty board” sensitivity, not only room-temperature startup.
  • Prefer designs with clear oscillator-fail indicators (flags or CLKOUT) to simplify bring-up and production screening.
Drive level and aging: when “it oscillates” is still not acceptable
  • Excessive drive level can accelerate aging and increase long-term drift.
  • Keep the design within the crystal’s recommended drive range; avoid “extra margin” strategies that raise excitation unnecessarily.
  • Long-term accuracy must consider aging rate and the calibration residual that remains after trimming.
Symptom → first suspect (fast fault isolation)
  • No oscillation: ESR limit, leakage/contamination, cold-corner start margin.
  • Fixed fast/slow time: CL mismatch, Cstray underestimation, capacitor asymmetry.
  • Temperature-sensitive failures: ESR vs temperature, mechanical stress, layout asymmetry.
  • Drift grows over months: over-drive, aging rate, unstable calibration metadata.
Figure 4 — Crystal equivalent model + two failure paths (CL error & leakage)
Crystal equivalent model with CL and leakage paths Diagram showing the crystal motional RLC with parallel C0, load capacitors C1 and C2, parasitic Cstray components, and a leakage path representing contamination and humidity, highlighting how CL mismatch and leakage impact frequency and startup. Equivalent model (motional branch + C0) and board loading OSC_IN OSC_OUT Crystal model Rm Lm Cm C0 Load network C1 C2 GND Cs Cs Cs = Cstray (pad/trace/input) Leakage path contamination / humidity Failure path A: CL mismatch → frequency pull → seconds/day error Failure path B: leakage reduces start margin → no-start / temp sensitivity

Oscillator circuit & layout for 32k (Placement, guarding, leakage)

The 32.768 kHz oscillator pins form a high-impedance, low-signal analog node. Robust start and stable accuracy depend more on placement, symmetry, guarding, and cleanliness than on the crystal part number alone. This section focuses only on the micro-sensitivity of the RTC 32k node (not system-wide EMI topics).

Placement & routing (copyable rules)
  • Keep the crystal close to the OSC pins (short, direct, minimal vias).
  • Route symmetrically: similar length, geometry, and ground environment on both pins.
  • Stay away from fast edges: DC/DC SW nodes, gate drives, PWM, high-speed IO.
  • Avoid human-touch zones: connectors, buttons, exposed edges (contamination/leakage risk).
Guarding & reference ground (what it protects)
  • Guard ring (GND) around the crystal and both traces reduces field coupling and gives leakage a preferred return.
  • Use continuous ground beneath the 32k region (no splits, no slots under the oscillator).
  • Do not cross a GND gap with OSC traces; the parasitic environment changes abruptly and reduces margin.
  • Keep heavy return currents away from the oscillator corner (avoid narrow “choke” ground paths).
Leakage & contamination (common root cause)

Flux residue, humidity, fingerprints, and dust can create microamp-to-nanoamp leakage paths that collapse start margin and pull frequency. The 32k node is especially vulnerable due to its high impedance.

  • Define a cleaning step in the build flow (clean → dry → store dry).
  • A/B verification: compare start success and seconds/day before vs after cleaning (or dry vs humid exposure).
  • If sensitivity is high, consider local protection (keep-out, coating strategy) without changing the oscillator physics.
External load capacitors (matching & tolerance strategy)
  • Match C1 and C2 (same value, tolerance, dielectric, and package) to minimize asymmetry.
  • Do not rely on typical CL; account for parasitics and capacitor tolerance in the accuracy budget.
  • Prefer deterministic tuning (estimate parasitics → choose C → measure seconds/day → adjust) rather than “swap until it works”.
Minimal verification map (prove the layout early)
  • Start: cold start + warm start + humidity/handling sensitivity checks.
  • Accuracy: evaluate in seconds/day using a low-intrusion output (e.g., 1 Hz/CLKOUT if available).
  • VBAT current: measure by mode (osc on/off, retention on/off, clkout on/off).
  • Reproducibility: check across multiple boards and multiple assemblies (not one “golden” sample).
Boundary lock

This section intentionally stays at the RTC 32k node level. It does not expand into full-system EMI compliance, backup-power switchover circuits, or disciplining loops.

Figure 5 — Layout Do/Don’t (32k oscillator node)
Layout Do and Don’t for 32.768 kHz oscillator Two-panel diagram showing recommended short symmetric routing with guard ring and continuous ground, versus long routing crossing ground gap near switching nodes and connectors. DO DON’T Short • Symmetric • Guard • Clean GND Long • Cross GND gap • Near SW/IO • Touch zones RTC / MCU OSC Crystal Guard (GND) Continuous GND RTC / MCU OSC Crystal Long trace GND gap SW Connector Noise

Accuracy budget: ppm today, drift tomorrow (Temp, aging, initial tolerance)

RTC accuracy should be budgeted and verified in seconds per day, not as a single “ppm” slogan. A practical conversion is 1 ppm ≈ 0.0864 s/day. Total error comes from multiple sources (initial tolerance, temperature drift, aging, and board loading), and any calibration leaves a residual that must be tracked.

Decompose the error (budget buckets)
  • Initial tolerance (@25°C): the baseline offset at room temperature.
  • Temperature drift: the full-range curve behavior across the required temperature envelope.
  • Aging (ppm/year): slow drift over months/years, often becoming visible in long holdover use cases.
  • Load/parasitics: CL mismatch, asymmetry, and contamination-induced leakage pulling the oscillator.
  • Calibration residual: what remains after trimming (and what must be verified, not assumed).
Engineering stance (avoids “typical-only” traps)
  • Worst-case thinking: budgets should use corner behavior and guardband, not only typical numbers.
  • Dominant term first: identify which bucket dominates before optimizing smaller contributors.
  • Short vs long horizon: daily error is often initial+temp; multi-year error must include aging and contamination sensitivity.
When compensation / calibration becomes necessary

Calibration is no longer optional when the combined initial + temperature buckets consume most of the allowed seconds/day budget, or when the product requires stable performance across wide temperature, humidity, and lifetime conditions.

  • Tight target: the allowed seconds/day leaves little room for drift and parasitics.
  • Wide environment: outdoor temperature swings, condensation risk, or large handling variability.
  • Long life: multi-year accuracy expectations where aging becomes a measurable term.
Verify by bucket (turn budget into a test plan)
  • Initial: measure seconds/day at room temperature against a trusted reference.
  • Temperature: measure at multiple stabilized points (soak) across the specified range.
  • Aging: trend the drift over time and preserve calibration metadata in a reproducible way.
  • Parasitics: compare clean vs contaminated handling and across board lots.
  • Residual: record before/after calibration and confirm the remaining error stays inside the target.
Boundary lock

This section stays within RTC timekeeping accuracy. It does not expand into high-speed clock jitter/phase-noise topics or GNSS/PTP disciplining loops.

Figure 6 — Accuracy budget waterfall (card-style buckets)
RTC accuracy budget buckets Card-style waterfall showing initial tolerance, temperature drift, aging, parasitics, and calibration residual contributing to total error, compared against a target in seconds per day or ppm. Total error budget s/day (or ppm) Initial Bucket size Temp Aging Parasitics Cal residual Target s/day Pass? Rule 1 ppm ≈ 0.0864 s/day

Calibration & compensation (Digital trim, temperature strategy, field flow)

RTC calibration improves timekeeping by correcting repeatable frequency error (ppm or seconds/day). A stable workflow is a closed loop: measure → compute → write → verify → store → monitor. It should not chase non-repeatable board leakage or contamination effects.

Common mechanisms (what the trim actually changes)
  • Coarse / fine trim: pull large offset back into range, then converge residual with smaller steps.
  • Add / sub tick: insert or delete ticks periodically to correct long-term average rate.
  • PPM trim register: program an offset in ppm-equivalent units (best for versioned workflows).
Strategy choice (factory once vs field periodic)
  • Factory one-time: controlled environment, stable reference, narrow temperature exposure, predictable assembly.
  • Field periodic: wide temperature, long lifetime, holdover use, or measurable drift over time.
  • Trigger definition: time-based, ΔT-based, drift-threshold-based, or post-event (battery swap, long power-off).
Data storage & versioning (prevents silent mis-calibration)

Store calibration as metadata + applied trim with a recoverable history. Prefer formats that support validation and rollback (CRC + version).

Recommended fields (minimum set)
offset trim temp time algo ver hw id CRC
Pass criteria (data-driven, not “looks good”)
  • Before/after delta: same measurement window, same reference, measurable improvement in seconds/day.
  • Temperature coverage: validate at representative temperature points, not only one point.
  • Residual tracking: record residual after trim; monitor slope/step changes as drift signals.
  • Reproducibility: repeat the loop and confirm the result is stable (no random “flip”).
Overfitting guardrails (practical rules)
  • Limit degrees of freedom: avoid complex curves when noise/parasitics dominate.
  • Separate compute vs verify: validate using different temperature points or time windows.
  • Respect the residual floor: stop trimming below the practical limit set by measurement + parasitic variability.
  • If trim distribution explodes: investigate layout/cleanliness/leakage before adding algorithm complexity.
Boundary lock

This section covers RTC-local calibration loops only. GNSS/PTP disciplining belongs to timing/synchronization pages.

Figure 7 — Calibration closed-loop flow (with metadata + drift monitor)
RTC calibration closed-loop flow Flowchart showing measure offset, compute trim, write register, verify, store metadata, and drift monitor feeding back into periodic calibration. Measure offset Compute trim Write register Verify before/after Store metadata temp time ver CRC Drift monitor time ΔT drift Key: verify with the same window & reference, store metadata, monitor residual Avoid chasing non-repeatable leakage/contamination effects with trims

Power, backup domain, and leakage (What kills battery life)

Backup current on VBAT is not a single number. It is the sum of RTC core, oscillator, retention / interface paths, and board leakage (often the dominant risk). Diagnosis must isolate variables in a controlled order.

VBAT current composition (the “sum of blocks” model)
  • RTC core: calendar counters and timekeeping logic.
  • Oscillator: 32k resonator or XO sustaining current.
  • Retention / I²C / INT: any kept-alive registers, pull paths, wake logic.
  • Board leakage: ESD parts, contamination, humidity films, fixtures, pullups, and back-power paths.
Leakage source checklist (board side is often the killer)
Common sources
ESD/TVS humidity flux fixture pullups GPIO state connectors
Measurement order (isolate variables, one at a time)
  1. Start with the RTC alone: VBAT only, main rails off, disconnect optional externals.
  2. Disable optional paths: CLKOUT, interface keep-alive, external pullups, unused interrupts.
  3. Add back stepwise: reconnect one path at a time and log the delta current.
  4. Check cleanliness: clean/dry vs humid/handled comparison to expose contamination leakage.
  5. Check temperature sensitivity: strong temperature slope often points to leakage components.
Quick attribution (IC vs board)
  • Large drop after removing pullups/IO: external paths dominate.
  • High sensitivity to humidity/cleaning: contamination leakage dominates.
  • Still high with everything disconnected: revisit RTC mode config and back-power paths.
Pass criteria (battery life becomes predictable)
  • Repeatable current: consistent across multiple boards and repeated measurements.
  • Mode-defined: current matches the documented feature set enabled on VBAT.
  • Stable after cleaning/drying: no order-of-magnitude swings under controlled handling.
Boundary lock

This section focuses on backup-domain current and leakage diagnosis. Backup switchover (coin-cell/supercap) belongs to a dedicated page.

Figure 8 — VBAT current decomposition (typ vs risk blocks)
VBAT current decomposition for RTC backup domain Block diagram splitting VBAT current into RTC core, oscillator, retention/interface, and board leakage, with typ and risk tags and a stepwise isolation hint. VBAT Backup-domain current blocks RTC core typ Oscillator typ Retention / I²C / INT mode Board leakage risk ESD humidity pullups connector fixture Diagnose: disconnect externals → measure RTC-only → add back one path at a time

Calendar, alarms, and timestamping (Behavior, edge cases, firmware hooks)

RTC functional correctness depends on deterministic calendar rollover, alarm compare semantics, and timestamp capture integrity. Time zone and daylight-saving adjustments are typically handled by the system layer; RTC should provide a stable local time base and predictable event hooks.

Calendar edge cases (what must be deterministic)
  • Leap-year / month-end / year-end: verify rollover behavior and invalid-value handling.
  • Atomic read: prefer latch/shadow registers, or re-read until consistent to avoid mid-tick field mismatch.
  • Safe set sequence: freeze updates (if supported), write fields in a defined order, then release and read-back.
  • Time zone / DST: treat as system policy; do not embed into RTC counting logic unless explicitly required.
Alarm semantics (compare logic, mask, wake latency)
  • One-shot vs periodic: periodic alarms are typically implemented via field masks (granularity defines behavior).
  • Mask granularity: compare-to-second vs compare-to-minute changes trigger windows and jitter sensitivity.
  • Flag & interrupt: confirm set/clear semantics (write-1-to-clear vs read-to-clear) and level vs edge interrupts.
  • Wake latency: alarm time is not MCU execution time; define acceptance using a system-specific latency budget.
Timestamp capture (trigger source, latch, race conditions)
  • Triggers: external pin, internal event, interrupt line, or scheduled capture (implementation-dependent).
  • Latch point: capture seconds-counter or full calendar fields; multi-byte reads require consistency handling.
  • Overrun risk: single-deep latches can be overwritten by back-to-back events; define an overrun policy.
  • Read/clear order: read status → read timestamp → clear flag to avoid missing or mis-associating events.
Recommended firmware hooks (portable, deterministic)
Read path
atomic read latch/shadow re-read verify
Write path
freeze update ordered fields read-back
Timestamp handling
read status read TS clear flag overrun rule
Boundary lock

This section focuses on RTC counting, alarms, and timestamp capture integrity. System time services (time zone/DST policies) belong to the software layer.

Figure 9 — Timestamp capture timing (simplified, race window highlighted)
RTC timestamp capture timing with race condition window Diagram shows event edge leading to latch, timestamp register update, flag set, MCU read, and flag clear, with a highlighted race window for overwrite/miss/inconsistent read. Event capture path MCU service path Event edge Sync / latch TS register Flag set MCU reads status + TS Clear flag Race window overwrite miss inconsistent Recommended order: read status → read TS → clear flag (define overrun policy)

Validation & measurement traps (How to prove your RTC is good)

RTC validation must separate accuracy, power, and robustness. The most common failure mode is proving the wrong thing due to measurement loading, incomplete mode definitions, or mixing short-term and long-term drift concepts.

Frequency measurement traps (loading is the silent killer)
  • Probe capacitance: measuring at the crystal pins can shift frequency or stop oscillation.
  • Instrument input impedance: frequency counters and long ground leads can inject coupling and bias.
  • Preferred nodes: measure buffered outputs (1 Hz / CLKOUT) when available, not high-impedance resonator pins.
  • A/B proof: compare “probe connected” vs “no probe” as a quick loading detector.
Drift validation (short-term vs long-term must be separated)
  • Bench (minutes-hours): quantify initial offset and repeatability in a stable environment.
  • Temperature: measure after soak/stabilization at representative points; avoid transient ramps.
  • Aging (days-months): log long-term trend with consistent reference and event annotations (calibration, power loss).
Power validation (modes + event peaks)
  • Define mode: oscillator on/off, retention/interface enabled, pullups present, CLKOUT enabled.
  • Separate domains: measure VBAT domain alone first, then add external paths one-by-one.
  • Event peaks: alarm/timestamp interrupts may create short peaks; capture and include in life estimates.
Production-ready minimum checks (fast, deterministic)
  • Accuracy spot-check: quick 1 Hz / CLKOUT rate check within a defined window.
  • Alarm self-test: configure → trigger → verify interrupt/flag clear semantics.
  • Timestamp self-test: inject event → read status/TS → clear flag → verify no mis-order.
  • VBAT mode current: sample by mode definition; flag outliers for leakage investigation.
Acceptance statement template (what “good RTC” means)
  • Accuracy: bench + temperature points meet the budget, and long-term trend is logged and explainable.
  • Power: VBAT current is repeatable by mode; event peaks are measured and accounted for.
  • Function: alarm and timestamp behave deterministically under defined concurrency and clear rules.
  • Robustness: cleanliness/handling/fixture variables are controlled and quantified.
Boundary lock

This section focuses on RTC validation and measurement pitfalls. Full system battery modeling and switchover circuits belong to dedicated power pages.

Figure 10 — Validation matrix (each cell = one minimal test action)
RTC validation matrix across environments Matrix with rows accuracy, power, alarm, timestamp, robustness and columns bench, temp, aging, production. Each cell contains a minimal test action label. Bench Temp Aging Production Accuracy Power Alarm Timestamp Robustness 1Hz check soak points trend log spot limit mode sweep ΔI vs T life model VBAT sample mask test latency repeat log IRQ + flag event inject sync check overrun rate event+flag clean vs handled humidity exposure batch tracking fixture control Rule: one cell = one minimal action (define mode, log result, keep it repeatable)

Engineering checklist (Bring-up → production → field)

This checklist compresses the RTC work into stage gates. Every line is written as Action → Evidence → Pass criteria, so design reviews, lab bring-up, production SOP, and field logs stay aligned without expanding into unrelated system topics.

How to use this checklist

  • Keep the stage order: schematic → layout → bring-up → production → field. Skipping stages usually hides leakage, loading, or flag semantics issues.
  • For any failure, log conditions (temperature, supply state, firmware version, probe/fixture used) before changing variables.
  • Stay within RTC scope: 32.768 kHz timebase, calendar/alarms/timestamp behavior, backup-domain current, and verifiable diagnostics.

1) Schematic review (before PCB)

Timebase & crystal network
  • Action: Confirm the intended topology (internal load caps vs external CL, series R if recommended).
  • Evidence: CL target and board parasitic budget written in design notes.
  • Pass: Crystal CL/ESR/drive limits are compatible with the oscillator spec and intended temperature range.
Backup-domain leakage paths
  • Action: Draw a “VCC-off, VBAT-on” pin-state matrix (I²C, INT, CLKOUT, GPIO).
  • Evidence: Schematic notes show which nets may back-power or pull current from VBAT.
  • Pass: No unintended pull-ups/ESD devices/IO states create a VBAT drain or reverse-bias path.
Diagnostics & debuggability
  • Action: Ensure oscillator-fail / missing-tick / alarm / timestamp flags are readable and logged.
  • Evidence: Firmware interface spec defines flag read order and clear semantics.
  • Pass: The design can prove “oscillator running” and “timestamp captured” without probing high-impedance crystal pins.

2) Layout review (placement, symmetry, guarding, cleanliness)

  • Action: Place the 32 kHz crystal next to the pins; same layer preferred; minimize vias.
  • Evidence: Layout screenshot annotated with crystal-to-pin distance and via count.
  • Pass: The crystal nets are short, symmetric, and avoid split planes and high dv/dt aggressors.
  • Action: Add a ground guard/keepout strategy around high-impedance nodes (where appropriate).
  • Evidence: Guard ring/keepout is explicitly shown in the layout review checklist.
  • Pass: No test pads or long stubs are attached to crystal pins; any measurement uses buffered outputs.
  • Action: Define cleanliness/flux-residue controls for the crystal area and backup domain.
  • Evidence: Manufacturing notes specify cleaning, handling, and humidity constraints for sensitive nodes.
  • Pass: The design has a documented plan to prevent leakage from residue, moisture, and handling.

3) Bring-up (prove it runs, then prove it behaves)

  • Action: Confirm oscillator start using buffered outputs (1 Hz / CLKOUT / status flags), not direct crystal probing.
  • Evidence: Startup time and “stable-running” condition recorded at room temperature.
  • Pass: Startup is repeatable and flags show “running” after each power cycle.
  • Action: Run minimal alarm and timestamp use-cases (single event + back-to-back event).
  • Evidence: Logs show correct flag set/clear semantics and no lost/duplicated timestamps.
  • Pass: Alarm IRQ and timestamp registers behave deterministically across reboots and sleep/wake cycles.

4) Production (calibration + records + fast screen)

Calibration SOP (minimum)
  • Action: Measure offset → compute trim → write trim register → verify → lock/store metadata.
  • Evidence: “Before/after” error logged using a consistent measurement window.
  • Pass: Post-cal error meets the product target (define as s/day or ppm in your requirement).
Mandatory record fields
  • Temperature (and soak status if applicable)
  • Trim value + algorithm version
  • Firmware version + timestamp of calibration
  • Pass/fail signature + operator/fixture ID
Fast production screen
  • 1 Hz / CLKOUT spot-check (no high-Z probing)
  • Alarm trigger + flag clear check
  • Timestamp capture + overrun behavior check
  • VBAT current spot-check by mode (define mode list)

5) Field (monitor drift, trigger re-cal, raise alarms)

  • Action: Trend RTC offset versus a known reference (short snapshots + long-term logs).
  • Evidence: Drift history stores temperature, power state, last trim, and firmware version.
  • Pass: Offset stays inside the allowed envelope; exceeding it triggers a controlled re-cal strategy.
  • Action: Log and act on diagnostics (osc fail / missing tick / alarm stuck / timestamp overrun).
  • Evidence: Field logs include raw flags + clear sequence results.
  • Pass: Faults are distinguishable (silicon vs board leakage vs firmware misuse) without lab-only instruments.
Figure 11 — Stage-gated flow (Design gate → EVT → DVT → PVT → Field)
Stage-gated RTC checklist flow Five stage gates with three must-pass items each: Design gate, EVT, DVT, PVT, Field. Design gate CL budget ESR margin domain rules EVT osc start 1Hz check IRQ + flags DVT temp soak drift log TS race PVT cal SOP records VBAT sample Field drift alarm recal rule fail flags Scope: timebase • calendar/alarms/timestamp • VBAT current • verifiable diagnostics

Applications & IC selection notes (RTC-only)

Selection should start from the task: required time error (s/day), whether calibration is needed, timestamp/alarm behavior, and the VBAT current budget by mode. Avoid turning RTC selection into a product list—use the template below to compare on evidence.

A) RTC-driven application groups (constraints that matter)

Data logging / metering
  • Goal: Preserve wall-clock time and event ordering across power loss.
  • Key constraints: Timestamp flag semantics, overrun behavior, and audit-friendly logs.
  • Minimal validation: Power-cycle loop + timestamp bursts + flag read/clear sequence.
IoT ultra-low power
  • Goal: Multi-year battery life with reliable alarm wake.
  • Key constraints: Mode-by-mode VBAT current and board leakage dominance.
  • Minimal validation: VBAT current breakdown (core/osc/IO pulls/leakage) + alarm latency checks.
Industrial instruments
  • Goal: Predictable long-term drift with a repeatable calibration story.
  • Key constraints: Temperature sweep coverage, aging logs, and re-cal trigger criteria.
  • Minimal validation: Temperature soak points + before/after trim + trend logging.
Low-cost time awareness
  • Goal: Cheap “time sense” where large error is acceptable.
  • Key constraints: Document the allowed error as s/day and enforce it in testing.
  • Minimal validation: Define and verify acceptable drift across temperature and supply states.

B) Selection field template (use cards instead of wide tables)

Fill these fields for every candidate. A candidate should be rejected quickly if any “Quick reject rule” fails.

Timebase support
Log: crystal / integrated XO / internal oscillator, and whether external CL is required.
Why: Determines bring-up risk and board sensitivity.
Quick reject: Timebase option does not match VBAT/current constraints or manufacturing capability.
VBAT current (by mode)
Log: oscillator + core + retention/interface + outputs (CLKOUT/INT pullups).
Why: Board leakage often dominates; mode definitions prevent false conclusions.
Quick reject: Cannot measure or specify VBAT current per mode consistently.
Accuracy features
Log: trim mechanism (offset register / add-sub tick / calibration steps) and resolution.
Why: Determines whether production/field calibration can reach the target s/day.
Quick reject: No usable trim path while the product requires tight drift control.
Alarm & timestamp behavior
Log: alarm masks, periodicity, timestamp inputs/sources, overrun flags, clear semantics.
Why: Many “RTC bugs” are really flag/ordering mistakes.
Quick reject: No clear way to avoid race conditions or prove capture correctness.
Interface, package, diagnostics
Log: I²C addr options, voltage domains, pin count, osc-fail/missing-tick flags, battery status.
Why: Enables reproducible lab tests and field audit without invasive probing.
Quick reject: No diagnostics to distinguish silicon vs board leakage vs firmware misuse.

C) Concrete reference part numbers (starting points only)

The following MPNs are provided to speed up datasheet lookup and lab comparison. Always verify package/suffix, voltage range, backup-domain behavior, and availability for your region and temperature grade.

RTC ICs (external 32.768 kHz crystal)
  • NXP PCF85063AT/AY (PCF85063A family; I²C RTC + offset trim)
  • NXP PCF8563T/5,518 (widely used legacy RTC; check “new designs” guidance)
  • Microchip MCP7940N-I/SN (SOIC-8) / MCP7940N-I/MS (MSOP-8)
  • Texas Instruments BQ32000D (SOIC-8) / BQ32000DR (packaging variant)
RTC modules / integrated timebase (lower bring-up risk)
  • Micro Crystal RV-3028-C7-32.768kHz-1ppm-TA-QC (ultra-low power class module)
  • Micro Crystal RV-8803-C7-32.768k-3PPM-TA-QA (high-accuracy module class; verify QA/QC suffix)
  • Epson RX8900CE:UA0 (I²C RTC module family; verify suffix like :UA0/:UB6)
  • Analog Devices / Maxim DS3231SN# (integrated TCXO + crystal; low BOM, accuracy-focused)
32.768 kHz tuning-fork crystals (SMD examples)
  • Epson FC-135 32.7680KA-A (SMD family; check CL option e.g., 12.5 pF / 9 pF)
  • Abracon ABS07-32.768KHZ-1-T (12.5 pF variant family)
  • Micro Crystal CM7V-T1A-32.768KHZ-12.5PF-20PPM-TB-QA (example suffix; verify CL/grade)
  • NDK MU00530-32.768K (7 pF example; verify CL/ESR and footprint fit)
Quick matching rules (crystal ↔ oscillator)
  • Match CL to the oscillator design target after subtracting board parasitics.
  • Keep ESR inside the oscillator’s startup capability across temperature.
  • Respect drive level to prevent accelerated aging or field failures.
  • Prefer buffered outputs (1 Hz/CLKOUT) for validation; avoid loading crystal pins.
Figure 12 — Task-driven RTC selection decision tree
RTC selection decision tree Decision tree: target error, calibration need, timestamp need, VBAT budget, then solution type outputs. Target error (s/day) define X, then branch Need calibration? trim / add-sub tick Need timestamp? flags / overrun VBAT budget mode-by-mode Solution type A MCU RTC + crystal (cost-focused) Solution type B RTC IC/module (lower bring-up risk) RTC-only: accuracy • power • alarms • timestamp • diagnostics (no secure/switchover/disciplining details here)

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs (RTC troubleshooting — actionable, scope-limited)

Each answer is intentionally short and executable: Likely cause → Quick check → Fix → Pass criteria. Scope stays within RTC (32.768 kHz timebase, calendar/alarms/timestamp behavior, backup-domain current, and verifiable diagnostics).

Crystal is populated but RTC never starts—what’s the first ESR/CL check?
Likely cause: ESR too high for the oscillator margin, CL target missed after board parasitics, or the crystal node is being loaded (probe/test pad/leakage).
Quick check: Avoid probing crystal pins; verify “osc running” using 1 Hz/CLKOUT or an oscillator-fail flag (OSF/OF/XTALFAIL or equivalent). Confirm the crystal CL rating matches the design target (after subtracting estimated parasitics).
Fix: Use a crystal with lower ESR (same CL), remove/shorten any stubs/test pads, and correct external CL values (or select “internal-cap” mode consistently). Clean the crystal area if leakage is suspected.
Pass criteria: Oscillator starts reliably across ≥10 cold power cycles; oscillator-fail flag stays clear; 1 Hz/CLKOUT is stable without touching the crystal pins.
Time is consistently fast/slow by a fixed amount—how to confirm CL mismatch vs trim setting?
Likely cause: The 32.768 kHz is offset due to CL mismatch/parasitics, or a trim register was left non-zero (factory default, calibration residue, or firmware bug).
Quick check: Read and log trim-related registers (coarse/fine ppm trim or add/sub tick control) and confirm they match the expected configuration. Compare the observed time error against a stable reference over a fixed window (e.g., 1–4 hours).
Fix: Reset trim to a known baseline, re-measure, then re-apply calibration intentionally. If the offset remains near-constant, adjust CL strategy (external caps or crystal CL selection) with parasitic budgeting.
Pass criteria: After baseline reset + re-cal, time error matches the target envelope (expressed as s/day or ppm) and is repeatable across reboots.
Drift changes a lot with temperature—what data should be logged first (temp points, ppm, mode)?
Likely cause: Temperature curve dominates (tuning-fork parabolic behavior), plus additional board-level parasitic/leakage changes with temperature or enclosure thermal gradients.
Quick check: Log (1) temperature at the crystal/RTC location, (2) power state (VCC vs VBAT, CLKOUT on/off), (3) time error as ppm or s/day at ≥3 soak points (cold/room/hot), using the same measurement window.
Fix: Stabilize measurement (soak + consistent window), then apply a temperature-aware trim strategy only if required. Reduce thermal gradients by placement/keepout and avoid heat sources near the 32k network.
Pass criteria: Drift vs temperature becomes explainable and repeatable; residual error after compensation stays within the product envelope at the defined temperature points.
VBAT current is 10× higher than datasheet—what’s the quickest leakage isolation sequence?
Likely cause: Board leakage or back-power paths (I²C pullups, INT/CLKOUT nets, ESD parts, contamination) dominate VBAT; the RTC IC itself is rarely the full 10× culprit.
Quick check: Isolate in this order: (1) remove external pullups to any always-on nets, (2) force GPIO/INT/CLKOUT pins to a known “no-drain” state, (3) disconnect external devices on the bus, (4) then compare “RTC-only” VBAT current.
Fix: Re-route pullups to the correct domain, add domain isolation (series resistors or FET isolation where appropriate), and enforce cleaning/handling controls around the crystal + backup domain.
Pass criteria: VBAT current returns to within a justified factor of datasheet (after including enabled blocks like CLKOUT) and scales predictably when each external path is re-enabled.
Alarm sometimes misses or fires twice—what register/flag race should be checked?
Likely cause: Flag clear/enable ordering is wrong, mask/compare logic is misconfigured, or the interrupt is level-sensitive and the flag is not cleared correctly (causing re-entry).
Quick check: Log the exact sequence around alarm setup: write alarm registers → clear alarm flag → enable alarm/IRQ → verify status. Confirm whether the IRQ is edge vs level and whether the alarm flag must be cleared before re-arming.
Fix: Enforce a single canonical sequence (clear flags before enabling, and clear flags immediately after handling). If supported, use “latch” or “one-shot” interrupt mode to avoid repeated firing.
Pass criteria: Over ≥100 cycles, the alarm triggers exactly once per scheduled event with no misses; flags and IRQ behavior match the defined state machine.
Timestamp captures look “off by one second”—what latch/atomic-read sequence is wrong?
Likely cause: Time registers and timestamp registers are read across a seconds boundary without proper latching/atomic read, or a “read-to-clear” flag is cleared too early.
Quick check: Use one I²C burst read (or a documented latch/freeze mechanism) for the entire timestamp/time tuple. Log: event edge time, TS flag set time, and the exact register read order.
Fix: Adopt a stable sequence: read STATUS/TS flag → burst read TS registers (and time if needed) → then clear TS flag. Avoid multi-transaction reads around the seconds rollover.
Pass criteria: With repeated event tests (including events near rollover), the timestamp ordering is consistent and the “±1 s” anomaly disappears.
RTC is accurate at room temp but bad after reflow—what contamination/cleaning sign points to leakage?
Likely cause: Flux residue/moisture creates leakage at high-impedance crystal nodes or load caps; reflow can also stress the crystal or change board parasitics if the layout is marginal.
Quick check: Compare VBAT current and frequency/time error before vs after cleaning. Inspect the crystal area (visual/microscope) and look for residue paths between the crystal pins, caps, and ground guard.
Fix: Enforce cleaning process, keep crystal nets short with guard/keepout, and avoid exposed test pads on crystal pins. If behavior persists, swap the crystal and re-validate.
Pass criteria: After cleaning (and/or crystal replacement), VBAT current and drift return to the pre-reflow baseline and remain stable over humidity exposure tests.
Oscillator works on bench but fails in enclosure—what thermal gradient placement issue is typical?
Likely cause: The 32k crystal sits in a thermal gradient (near regulators, shields, batteries, or airflow edges), causing temperature-dependent startup margin or large drift.
Quick check: Measure local temperature near the crystal/RTC in the enclosure and compare to the bench. Correlate “fail-to-start” or drift with temperature and airflow conditions (fan on/off, lid open/closed).
Fix: Move the crystal/RTC away from hotspots, add thermal shielding/keepout, and ensure the oscillator network is not routed through heat gradients.
Pass criteria: Across enclosure conditions (worst-case airflow and temperature), oscillator start is repeatable and drift remains within the defined envelope.
After firmware time set, it jumps back—what write order/hold bit is commonly missed?
Likely cause: Time is written without using the device’s recommended “hold/freeze/stop-update” mechanism, or shadow registers are not committed correctly; a stale value may be restored after a flag event.
Quick check: Log the exact write sequence (register order + whether a hold/stop bit is used). Immediately read back all time registers in one burst read and confirm the oscillator-stop flag and status bits are cleared per datasheet.
Fix: Use the documented set-time procedure: enter hold/freeze (if available) → write time registers in required order → exit hold/freeze → clear relevant status flags → verify with a burst read.
Pass criteria: After setting time, repeated reads over multiple seconds show monotonic time progression and no reversion after sleep/wake or power transitions.
Production calibration looks great, but field drift grows—how to distinguish aging vs temp model error?
Likely cause: Aging produces a slow monotonic shift over time, while a temperature model error shows drift correlated with temperature excursions or operating modes.
Quick check: In the field log, record (1) temperature, (2) mode (VCC/VBAT/CLKOUT), (3) current trim value + version, and (4) observed time error at periodic intervals. Plot error vs temperature and error vs time.
Fix: If temperature-correlated, refine temp-point coverage or compensation mapping; if time-correlated, schedule periodic re-cal or widen guardbands to account for aging.
Pass criteria: Error is decomposed into a predictable component (temp) and a slow component (aging), and re-cal triggers keep the total error within the product envelope.
32k output looks distorted—how to tell loading/probing artifact vs real oscillation issue?
Likely cause: The measurement setup loads the high-impedance node (probe capacitance), or the oscillator is marginal (ESR/drive/parasitics/leakage), producing a genuinely deformed waveform.
Quick check: Do not probe crystal pins directly. Use CLKOUT/1 Hz output, or measure through a high-impedance active probe/buffer point if provided. Compare “probe on” vs “probe off” behavior.
Fix: Move validation to buffered outputs; if the oscillator is marginal, reduce parasitics, remove stubs, improve guarding/cleanliness, or select a crystal with appropriate ESR/CL.
Pass criteria: “Probe-on” does not change oscillator start/stop behavior; buffered outputs remain stable and frequency/time error matches expectations.
Why does enabling CLKOUT increase VBAT current—what block did I wake up?
Likely cause: CLKOUT enables an output buffer/divider that runs continuously in backup mode, or it forces a higher-power oscillator/retention state.
Quick check: Measure VBAT current with CLKOUT off vs on, and log the exact control bits (CLKOUT enable + frequency select + output drive). Confirm whether CLKOUT is sourced from backup-domain power.
Fix: Keep CLKOUT disabled in backup mode (enable only under VCC), reduce CLKOUT frequency/drive if supported, or use 1 Hz only during lab validation.
Pass criteria: The delta current matches the datasheet “CLKOUT enabled” mode, and the product battery-life budget remains satisfied in the intended power state.
icnavigator

ICNavigator helps engineers find verified ICs, alternatives, and fast quotes.

Explore
Categories
  • Power Management
  • MCU
  • Automotive ICs
  • Sensors
  • Interface & Transceivers
  • Analog Front-End
Get in Touch
  • Email: hello@icnavigator.com
  • WeChat/WhatsApp: +86-xxxx

© 2025 ICNavigator. All rights reserved.