RTC Replacement for new PCB Revision

Replacing a Real Time Clock and writing drivers for a new PCB Revision. Work Project

Project Overview

This project involved updating legacy embedded firmware to support a new hardware revision after a critical component was discontinued. Specifically, a real-time clock (RTC) on the ProHeat product line was replaced with a newer, functionally equivalent device, requiring a new driver implementation and SPI interface updates on the microcontroller.

The objective was to maintain product viability without rewriting large portions of an aging codebase, while ensuring future hardware revisions could be integrated with less friction.

Technical Scope

  1. New RTC Driver Development:
    A complete driver was written for the replacement RTC, including initialization, register access, and timekeeping functionality. The implementation was designed to match the expectations of the existing firmware to minimize downstream changes.
  2. SPI Interface Integration:
    The microcontroller’s SPI configuration was updated to support the new device and the latest PCB revision. This included timing, mode selection, and data framing adjustments required for reliable communication.
  3. Legacy Codebase Integration:
    The driver was integrated into a large, aging codebase with limited abstraction and sparse documentation. Care was taken to avoid breaking existing functionality while introducing support for the new hardware revision.

Debugging & Validation

  1. Hardware-Level Debugging:
    Due to uncertainty around the SPI implementation, an oscilloscope was used as a sanity check to validate clock polarity, phase, chip select behavior, and data timing. This ensured the firmware behavior matched the RTC’s datasheet rather than relying solely on software assumptions.
  2. Dead-Bug Prototyping:
    Early validation was performed using a dead-bug setup with the new RTC manually wired into the existing board. This allowed driver bring-up and signal verification before finalized hardware was available.

Challenges

Legacy Firmware Constraints.
The existing firmware was large, tightly coupled, and not designed with frequent hardware changes in mind. Limited abstraction and sparse documentation made driver integration difficult, as small changes could affect unrelated subsystems. Careful isolation and incremental validation were required to avoid regressions.

Fine-Pitch Dead-Bug Rework.
Before finalized hardware was available, the replacement RTC was dead-bugged and soldered under a microscope. Individual wires were attached to fine-pitch pads (approximately 0.5 mm pitch across a 16-pad package). The connections were fragile and frequently detached during adjustment and probing, making stable bring-up non-trivial.

Figure 1: Probed RTC

SPI Signal Verification.
Due to both the legacy codebase and the fragile physical setup, updating the SPI interface was difficult. An oscilloscope was used to directly probe the SPI bus and confirm clock polarity, phase, chip-select behavior, and data validity. This step was critical in distinguishing firmware issues from physical connection failures and confirming successful communication with the RTC.

Yellow is CS, Cyan is MISO, Purple is MOSI and Blue is Clk

Figure 2: Dead-bug RTC with fine-pitch soldered leads (microscope view)
Figure 3: SPI Request
Figure 4: SPI Request and Receive
Figure 5: RTC sending Hours, Minutes, Seconds, Day of Week, Day, Month and Yea

Results & Impact

The updated driver and SPI integration successfully enabled the new hardware revision, allowing the product to continue shipping despite component obsolescence. The work also established a clearer pattern for supporting future hardware changes, reducing the long-term maintenance burden.

Without this update, the product would have been blocked by supply chain constraints. With it, the hardware transition became a contained firmware change rather than a full redesign.

Conclusion

This project demonstrated practical embedded development skills under real-world constraints: legacy code, minimal documentation, hardware uncertainty, and business-critical deadlines. By validating behavior at the signal level and carefully integrating new drivers, the system was extended without destabilizing existing functionality.