One of my colleagues is designing a digital clock with 7-seg displays. The clock function is shouldered by a Real-Time Clock IC, PCF8563.

The RTC IC is clocked with a 32.768kHz crystal and its external caps (one cap is a fixed one and the other one is a trimmer for frequency trimming). The trimming is guaranteed by measuring 1Hz output (test frequency) function of the RTC IC using a precision counter/frequency meter. By the way, the communication protocol between MCU and the RTC IC is I²C with a speed of 400kHz.

Instead of using 7-seg display modules (like this one), he decided to use discrete 0603 case SMD LEDs for 7-seg display effect (this is important) and cost-effectiveness. He placed these LEDs on one side of the PCB, and the other side is full of other components (i.e. regulator, MCU, backup battery, RTC IC, driver ICs etc). The PCB is made from 1.6mm FR4 material.


The displays are multiplexed with a frequency of 100Hz (min). Before the LEDs light up, test frequency measured from RTC IC's output can be trimmed to 1.00000Hz. But, once the MCU starts multiplexing the LEDs, test frequency shifts to 1.5Hz or even 2.5Hz and stays unstable.


Grounding the crystal's outer metal case, adding ground areas, adjusting multiplexing frequency did not work. It's quite interesting that using 7-seg display modules or separating RTC IC and its external components (i.e. crystal and caps) to another PCB does not cause any problem(s).


Despite using a separate PCB for the RTC block or using 7-seg display modules solves all the problems, he is restricted with using only one PCB housing all the components. So, what can cause this frequency shifting problem? What should be done to deal with this?

  • 1
    \$\begingroup\$ schematics.. pcb layout would help \$\endgroup\$
    – Trevor_G
    May 10, 2017 at 9:06
  • 1
    \$\begingroup\$ @Trevor Not possible. Because it's a commercial product. \$\endgroup\$ May 10, 2017 at 10:09
  • 1
    \$\begingroup\$ Hard to help then. I suggest isolating the RTC to some corner of the board away from the LED track runs, and feeding it with it's own ground from the power plug and filtered power rail. Then ground pour on the rear under it. \$\endgroup\$
    – Trevor_G
    May 10, 2017 at 10:11
  • 1
    \$\begingroup\$ @Trevor Thanks. 2 LEDs per segment, 7 segments per digit and 4 digits mean 56 LEDs in total, so a lot of LED tracks :) Okay, I'll tell him to do so. By the way, I told him that using 3- or even 4-layer PCB having GND as one of the inner layers would help. What do you think? \$\endgroup\$ May 10, 2017 at 10:15
  • 3
    \$\begingroup\$ Yes I was going to suggest a ground plane would help. Though multiplexed leds wont be able to take much advantage of that. Make sure you have enough caps on whatever is driving those leds too. You are switching quite a bit of current. \$\endgroup\$
    – Trevor_G
    May 10, 2017 at 10:19

1 Answer 1


As your colleague cannot provide the schematics or PCB layout, any answer can only be a "best efforts guess" as we can't see what the design actually is.

using a separate PCB for the RTC block or using 7-seg display modules solves all the problems

This tells us that moving the RTC, or the different schematic & PCB design for the 7-segment displays, is enough to solve one or more of the problems with the design - at least enough for it to appear to work (although some design problems might still remain, even when a design appears to work).

RTCs typically use a low-power crystal drive signal (to save power) and high impedance input, but this makes them sensitive to interference from nearby signals. If such interference happens, those additional transitions of the OSCI signal will make the clock run faster, which is your symptom.

Moving the RTC to a separate PCB obviously increases the distance from potential interference sources to the OSCI signal, so this suggests one or more interference sources are coupling into that signal (or coupling into the OSCO signal, which then affects OSCI).

NXP provide a helpful document - UM10301 User Manual for NXP Real Time Clocks PCF85x3, PCF85x63, PCA8565, PCF2123, and PCA21125 - which includes design guidelines to avoid this type of problem. Your colleague's existing design will likely be breaking one or more of these guidelines, which is causing the problem you describe.

It is best to read the whole document, but one of the relevant sections is section 14 which I have included below. This includes the PCB layout guidelines. Follow them. It is possible that your colleague's design will start to work correctly before making changes to follow all the guidelines, but all of them should be considered for the best noise immunity and design reliability.

PCB layout guidelines from NXP document UM10301, part 1

PCB layout guidelines from NXP document UM10301, part 2

PCB layout guidelines from NXP document UM10301, part 3

  • 1
    \$\begingroup\$ We also suspect that the interference is the source of problems. Your explanations as well as the document you provided (which is the one that we are looking for) proved that. Thanks anyway. \$\endgroup\$ May 10, 2017 at 12:47
  • 1
    \$\begingroup\$ We updated the PCB according to the suggestions and made a test last week. It works like a charm! Thank you! \$\endgroup\$ Jun 22, 2017 at 9:45
  • \$\begingroup\$ @RohatKılıç - That is good news, thanks for the update :-) \$\endgroup\$
    – SamGibson
    Jun 22, 2017 at 10:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.