A real-time clock (RTC) is a dedicated peripheral or external IC that tracks calendar time (seconds, minutes, hours, date, day, month, year) independently of the main CPU, typically powered by a coin-cell battery or supercapacitor so it continues running when the rest of the system is off or in deep sleep.
In practice
RTCs appear in any system that needs to timestamp data, schedule wake-up events, or display wall-clock time: data loggers, industrial controllers, medical devices, smart meters, and consumer electronics. On many microcontrollers -- including STM32, nRF52, and SAMD -- the RTC is integrated on-chip, running from a low-frequency 32.768 kHz crystal on its own power domain. On MCUs that lack a built-in RTC (such as many PIC and AVR parts), an external I2C or SPI RTC IC is added, with common choices including the DS1307, DS3231, and PCF8523.
Accuracy is a key design concern. A basic RTC crystal drifts anywhere from a few seconds to several minutes per month depending on crystal tolerance, temperature variation, and aging. The DS3231 integrates a temperature-compensated oscillator and typically achieves accuracy within a few minutes per year. For tighter requirements, periodic synchronization over NTP, GPS, or a precision time source (such as IEEE 1588 PTP) is used instead of relying solely on the local oscillator. The EmbeddedRelated article "Real-time clocks: Does anybody really know what time it is?" covers drift sources and compensation strategies in depth.
A frequent pitfall is confusing the RTC with the system tick or a general-purpose timer. The system tick (often a 1 ms SysTick on Cortex-M cores) counts uptime from reset but does not survive power loss and accumulates drift differently. The RTC is the appropriate source for wall-clock time and calendar-based wake-up alarms. Another common issue is neglecting to handle the RTC's shadow register or synchronization latency: on many STM32 devices, reading the time registers while a sub-second update is in progress requires waiting for a sync flag or reading twice and comparing.
On low-power designs, the RTC alarm is often a primary wake source that brings the MCU out of deep sleep (STOP or SHUTDOWN mode on STM32, System OFF on nRF52), though most MCUs also support additional wake sources such as GPIO pins, comparators, or external interrupts depending on the low-power mode. This makes the RTC central to energy budgeting: the oscillator and RTC register file may draw only around 0.5--2 uA from the backup supply on some devices (exact figures vary widely by IC, configuration, temperature, and crystal load), while the rest of the chip is fully powered down.
Frequently asked
What crystal frequency does an RTC use, and why?
Most RTCs use a 32.768 kHz
crystal, though some devices use integrated RC oscillators or MEMS-based references instead. The 32.768 kHz frequency is exactly 2^15 Hz, so a simple 15-stage binary divider produces a precise 1 Hz tick in hardware. The low frequency also means very low oscillator power, which matters when running from a coin cell for years.
What is the difference between an RTC and the system tick timer?
The system tick (such as SysTick on Cortex-M) is a configurable timer driven by the main clock tree, commonly set up to tick every millisecond, that counts elapsed intervals from the last reset. It stops whenever the core is halted or powered down, and its count is lost on reset. The RTC is a separate low-power counter that tracks calendar time and continues running from backup power even when the main supply is off, making it the correct source for wall-clock timestamps and timed wake-ups.
Do I need an external RTC chip if my MCU has one built in?
Not necessarily. Integrated RTCs on parts like STM32L, nRF52840, or SAMD21 are fully capable for most applications. An external IC such as the DS3231 is worth considering when you need better accuracy (its temperature-compensated oscillator outperforms a typical on-chip RTC with a bare
crystal), when you need features like programmable square-wave output, or when the
MCU lacks a dedicated backup power domain.
How do I handle RTC drift over long periods?
For applications where drift of seconds per month is acceptable, calibration at manufacturing time and periodic resets are sufficient. For tighter accuracy, use a temperature-compensated external RTC, apply software calibration using the correction
registers available on many integrated RTCs, or synchronize periodically to an external time source such as NTP (over Wi-Fi/
Ethernet), GPS, or a DCF77/WWVB radio signal.
Why do I sometimes read wrong values from the RTC time registers?
Many RTC peripherals -- particularly those on STM32 devices -- use shadow
registers that are refreshed from the internal calendar counter once per second. Reading during the update window can yield a stale or inconsistent value. The correct approach is to poll the RSF (registers synchronization flag) after wakeup from
low-power mode, or to read the time register twice and accept the value only when two consecutive reads match.
Differentiators vs similar concepts
RTC vs. system tick / general-purpose timer: A system tick or GPT counts elapsed time from reset using the main clock and stops when the core is halted or unpowered. An RTC tracks absolute calendar time from a dedicated low-power oscillator and survives main-supply loss via backup power, making it the correct choice for wall-clock timestamps and timed wake-up alarms. The two are complementary: the system tick is used for task scheduling and timeout measurement at fine resolution; the RTC is used for date/time and coarse scheduled events. See also the related discussion in "A Working Real Time Clock (RTC) Implementation" on EmbeddedRelated.
