Inside Microcontroller Real‑Time Clocks (RTCs): Design, Accuracy, and Security

Part 3 of the Microcontroller Timers Series: Inside Real‑Time Clocks (RTCs)

In this installment we dive into the heart of microcontroller‑based real‑time clocks (RTCs). Previous posts covered timer fundamentals and pulse‑width modulation. This article explains how RTCs maintain accurate one‑second intervals, manage time and date, compensate for drift, and safeguard against tampering.

What an RTC Does

RTCs are dedicated hardware that generates a steady one‑second tick and keeps a continuous count. A simple timing diagram shows the tick generator, a software routine that reads the seconds counter, and an alarm that fires three seconds later. The key requirements are accuracy and continuous operation.

Figure 1. Basic RTC timing diagram

Typical Hardware Features

Modern microcontroller RTCs usually include:

• an internal 32 768 Hz oscillator (often with a crystal or TCXO option)
• an external clock input that can provide a highly accurate reference
• a multiplexer to select the source, followed by a prescaler that divides by 32 768 (2¹⁵) to generate the 1 Hz tick
• a 32‑bit (or larger) seconds counter, and optional counters for minutes, hours, days, months, and years
• a 1 Hz square‑wave output pin
• interrupt pins for alarms, second ticks, or other events
• a dedicated backup power pin, usually a coin‑cell battery, so the clock keeps running when the rest of the chip is powered down

Figure 2. Common RTC hardware features

Accuracy and Frequency Compensation

The heart of an RTC is its 32 768 Hz crystal. In a well‑designed oscillator, the crystal itself is the main source of error. External TCXOs can deliver sub‑ppm stability, while internal oscillators can be compensated to achieve comparable performance.

Typical error sources include:

• initial tolerance of the crystal and surrounding circuitry
• temperature‑drift, which follows a predictable quadratic curve
• aging, usually only a few ppm per year

The graph below, courtesy of Texas Instruments, illustrates how temperature and initial error combine, and how careful calibration can bring the total error into the yellow band—an achievable target after board‑level measurement.

Figure 3. Error vs. temperature (Texas Instruments)

With 1 ppm accuracy over a year, the clock deviates by roughly 30 seconds—far better than most hobby projects but still worth accounting for in mission‑critical systems.

Compensating Timing Errors

Two common strategies exist to correct small drift without sacrificing the simplicity of the hardware:

Adjustable prescaler. If the RTC exposes a programmable prescaler, software can tweak the modulus every few seconds. For example, a clock that runs 0.00010 s fast can change the prescaler from 32 768 to 32 781 once every fourth second, adding the missing 0.00010 s each time.

Figure 4. Prescaler adjustment to counter drift

Advantages: fine‑grained corrections and minimal code. Drawback: requires an adjustable prescaler and extra registers.

Software correction. When the hardware lacks a programmable prescaler, the firmware can keep a running tally of the seconds counter. When the accumulated error reaches one second, it adds or subtracts a tick. The adjustment is visible only once per cycle, which can feel abrupt.

Figure 5. Software‑only timing correction

Advantage: works with any RTC. Disadvantage: noticeable jumps in the tick rate.

Security Considerations

In applications where time is tied to billing, usage limits, or critical sequencing, protecting the RTC from tampering is essential. Many microcontrollers provide:

• write‑protected registers that can be permanently locked by software
• hardware reset requirements to modify the time (a full reset erases the lock)
• enclosure‑level intrusion detection to alert on physical tampering

For example, the MCU used in this article has a lock bit that, once set, cannot be cleared until the chip is reset, preventing rogue code from altering the clock.

Managing Time and Date

Some RTCs integrate full time‑of‑day and calendar counters. If the hardware lacks these, the firmware can derive the date from the 32‑bit seconds counter using standard algorithms. The C standard library’s time.h expects a function that returns seconds since the epoch (usually Jan 1 1970). A simple get_time() wrapper that reads the RTC’s counter feeds the library, which then handles leap years, daylight saving, and formatting.

Limitations of 32‑Bit Second Counters

A 32‑bit counter will overflow after 2³² seconds—just over 136 years. However, when the epoch starts in 1970, the counter will roll over in 2038 (the Y2038 problem). Systems relying on the C library can experience undefined behavior when the counter reaches 2³¹ – 1.

NASA’s Deep Impact mission lost communication in 2013 after a 32‑bit timer that tracked time in 0.1‑second increments rolled over, potentially corrupting control commands.

“Although the exact cause of the loss is not known, analysis has uncovered a potential problem with computer time tagging that could have led to loss of control for Deep Impact’s orientation.”

— NASA News Release, 2013

Designers should use counters that comfortably exceed the expected lifetime of the system, or implement rollover handling in firmware.

Next Steps

The final article in this series will cover watchdog timers, the safety net that keeps a microcontroller alive even when software hangs.