I am looking for help troubleshooting a couple of shift registers that seem to be unstable in a digital wall clock that I've built back when I was active in this stack, back in 2014.

More than fixing the clock, I'd like to learn how to troubleshoot and identify problems with shift registers when they show signs of instability, preferably using an oscilloscope.

The Device Under Test (DUT)

The clock being troubleshot is this one below.

Digital wall clock working correctly, displaying time and date - 16:22 (4:22PM) 23/04/22 (04/23/22)

In the picture above, it's displaying the right time and date - 16:22 (4:22PM) on 23/04/22 (04/23/22) - at the time the picture was taken, obviously :D

It used to work fine until the two first digits (the ones displaying the hour above - 16) started to flicker like in the animated GIF below.

Animated GIF showing the display glitching

The (sub-optimal, noob level) Design

For reasons, I didn't want to multiplex the digits, so I designed the clock so that every segment on every digit was driven by a separate port on a shift register. Each 7-segment display digit is driven by a combination of a 595 shift register and a Darlington pair from a ULN2003. The registers are then daisy-chained together in a total of 10 "modules" to drive all 10 digits. The whole clock is controlled by an ATMega328P-PU MCU.

Below are the schematics of the three boards that make up the design (one controller and two digit driver boards). Please bear in mind that it is a very sub-optimized design made by a hobbyist with archaic (pre-1950) building capabilities, who thought himself electronics (mostly from this very own stack!!). It's not designed to be mass produced or even to exist beyond this single prototype.

Control board

The schematics above is for the control board. It contains the microcontroller and other modules (like a serial RS-232 driver, the real-time clock IC and battery cell, a 434MHz radio signal receiver for the remote control etc.). This is connected to two other boards that contain the shift registers and Darlington pair ICs. They are connected through connectors JP1 and JP2, which have short cables connecting them. Their schematics are below.

7-segment driver boards

The schematic above is used to control the 4 larger 7-segment digits that display the time of day, and are placed on top of the clock. There's another similar board that controls the lower 6 digits, that show the date (similar schematics, which I don't have, just with 2 extra digit driver modules.)

More details about the desing:

  1. The 7-segment display digits are 12V commom-cathode (CC). They are connected to VIN and their low side is driven through ULN2003, which in turn are driven by the 595 shift registers; The digits are connected to the pairs of connectors on the top of the 2nd schematics, through connectors SV1+SV2 (digit 1), SV3+SV4 (digit 2), and so on...
  2. There's a 5V rail (converted down from the 12V rail using an LM7805 linear voltage regulator) to power the control board and its various ICs (MCU, RTC, radio receiver etc) and the display drivers (shift registers); Not much current is drawn from the LM7805, so there's no heating issues that I could foresee;
  3. All ten 595's are daisy-chained (the ones glitching are the last ones in the chain). They are all driven by the same MCU pair of ports: clock and latch;
  4. each board has its own serial in, 5V rail and enable signals; the latter are connected to PWM ports to control segment intensity;
  5. All 595's have their decoupling ceramic 100nF cap (famous 104 cap) placed near their VCC pin (GND pin is on the other side of the package, unfortunatelly);

The Boards

Below are some pictures of all the boards.

All boards

Control board

Display driver board 1

enter image description here

enter image description here

Troubleshooting So Far

The problem, as seen in the short film above, is a glitch on two of the digits, namely, those driven by IC5+IC6+SV5+SV6 and IC7+IC8+SV7+SV8, on the second schematics. Those are the last ones in the shift register chain.

I do own a 70MHz Agilent entry level oscilloscope, but I don't know exactly what to probe to find the problem. I looked at all the signals (serial in/out, clock, enable, latch) and rails (GND, 5V, 12V), but no luck. Everything seems to be ok, except for a large ripple (500mV) that I detected on the 5V rail near the shift register VCC pins. They spikes are in sync with the clock (or latch, I don't remember, sorry).

Not being able to determine what is causing the problem, I've tried the following specific fixes to the boards, without any results:

  1. I replaced the glitching 595 and ULN2003, to no avail;
  2. I replaced the LM7805 voltage regulator and both of its capacitors;
  3. I switched the order of the 2 daughter boards to check if the problem was with the last registers in the chain. This messed up the digits displayed, but the same digits (two upper left ones) continued to glitch regardless of the order in the register chain;
  4. Replaced the decoupling cap on IC7 and moved it closer to VCC, because it was farther away from it originally;

The Questions

My main question is whether there's a way to generically troubleshoot a chain of shift registers to fix these kinds of glitches. Where should I put the scope probes on? Is a 500mV ripple on the 5V rail powering the registers too much?

Second question is how to fix my specific problem, described above. What else should I try? Where else should I probe, to check for problems? If you want me to probe any particular points in the boards, I can edit the question and include scope shots if that would help.

Third and last question, could it be that the clock and latch signals are exceeding the fan out of the respective MCU ports? Could this be the problem? How do I check with a scope? Should I break them down to control two sets of five digits separately?

It's really nice to get back here after so many years and meet some friends again. I hope to hear from you really soon.

Thanks for reading!!!

  • 2
    \$\begingroup\$ If they're flickering constantly, it should be easy to trace the problem at least to some degree. Start at the LED for the digit that's flickering, and if that looks normal (i.e. the high and low voltage levels seem correct), then move to the darlington, then move to the shift register, then to the microcontroller. At some point in that chain, you will find a subsystem where the input is functioning as expected, but the output is not. For example, if it was the darlington, you would see voltages on the input that dont match what you expect the voltages on the output to be \$\endgroup\$
    – BeB00
    Apr 23, 2022 at 22:26
  • 3
    \$\begingroup\$ ”Is a 500mV ripple on the 5V rail powering the registers too much?” That is a lot, but can’t say for sure it would case a problem. How did you measure it? \$\endgroup\$
    – winny
    Apr 23, 2022 at 22:38
  • 2
    \$\begingroup\$ The faster the ripple, the less loop area of your probe+ground setup you need. Also, when in doubt, add more decoupling capacitors. \$\endgroup\$
    – winny
    Apr 23, 2022 at 23:46
  • 3
    \$\begingroup\$ @winny - Added more decoupling caps and it fixed the problem. I've added one 10uF electrolytic to the board power input and 3x 10nF ceramics, one to each 595 IC near the problem area. Dawn! I'm still watching to see if the glitch comes has gone away for good, but thanks a lot for helping out!! "When in doubt, add more decoupling capacitors." I'll write that down a hundred times. And then some more. \$\endgroup\$
    – Ricardo
    Apr 24, 2022 at 11:37
  • 2
    \$\begingroup\$ Excellent! Glad to be of service! \$\endgroup\$
    – winny
    Apr 24, 2022 at 12:57

3 Answers 3


Without specific knowledge of your circuit and especially how your setup was to determine 500 mV ripple, this number caught my attention.

If you have a very large area formed by your ground lead from your probe going somewhere else on the board, several cm away, this may just be an artifact from bad probing. If you on the other hand have very good setup, this is a very high figure of 10 % ripple.

While 4.5 V is not enough to put your circuits out of Vcc spec, you will have a plethora of other effects which will degrade your signal integrity. For a clocked system, this is even worse.

I do see in your schematic that you have ceramic decoupling capacitors for some of your ICs, but no value stated in the schematic. Ideally, you want at least 100 nF as close to the Vcc and GND pins of each IC as possible. To make matters worse, a two layer board with lots of though holes for your components will degrade your ground plane a lot due to less capacitance and more inductance.

As a first step, add more decoupling, at least one 100 nF for each IC.

Ideally, move to SMD components in order to not penetrate the ground plane. Even better would be a four layer design with an unbroken ground layer.

Here is an example I borrowed from https://www.reddit.com/r/AskElectronics/comments/ttbcg2/question_about_decoupling_capacitor_with_ic/?utm_source=share&utm_medium=ios_app&utm_name=iossmf: enter image description here

The vias will connect to a ground plane below the top layer.


Two major culprits I've found are crosstalk and as you've suggested, fan-out on the CLK predominantly. Crosstalk can be mitigated in your case by separating the wires whereas if you'd used a flat cable, then you'd need to have gnd circuits interspersed between the signals.

Adding buffers like 74HC125 or 74HC244 to provide better drive of the clk signal should improve your situation. Also consider ground bounce, so ensure your gnd wiring is heavy enough a wired to a common star point if possible.

How to debug? This can be tricky due to what the others have commented. Ground bounce can confuse the situation depending on where your scope ground lead is connected. There's ringing, crosstalk and setup/hold timing. The setup/hold timing gets worse the further along the chain you go.

  1. Ground bounce - put the scope ground lead at the driver end. Probe the gnd at each of the sub-boards. You hope that the amount of bounce is < 1V. Less is better.

  2. Cross talk. Scope the clock and the data lines. If the clock glitches when the data changes, that is probably cross talk. It is also possible your latch signal induces a glitch onto the clk.

  3. Setup and hold timing. Scope your clock and data lines. The data should be stable for the require time before the clock edge and held for the required time after the clock edge. Refer to the HC595 datasheet for the actual times.


For years I've always had problems with the 595. I've tried different decoupling caps and filtering on control lines.... just about everything suggested by everyone in this article.

The main issue with the 595 is the Serial Clock. I eventually found that the changing the clock SLEW RATE solved everything. It seemed that the data been clocked would be out by a bit or 2.

I ran the Clock from the SPI port on the microcontroller at 1MHz. A simple LOW PASS RC filter on the Clock solved everything. At 1MHz I used a 1K resistor with a 22pF cap to ground. The Filter slows the SPI Clock pulse (t=RC) enough for the 595 Clock circuitry to correctly interpret the Signal correctly.

I will never again use the 595 due to the clock issue but this simple fix resolved older boards I had. Also the 595 is a noise detector, If you running the circuit from the same mains supply where large machinery is active it will affect it. Best stay away from 595, its great for a quick fix for small hobby projects (home use) but terrible in industrial applications.

  • 2
    \$\begingroup\$ I think the problem is not with 595 but how you use it. Generally it does not like slow clock transitions so there should not be need to slow down the slew rate due to the 595 itsef, but the rest of the system can't handle the sharp edge. It may be bad PCB board design, bad or long wiring design between boards, missing bypass caps or something similar. Transmission line effects and inductance of ground wiring comes into play with fast edges. \$\endgroup\$
    – Justme
    Jul 13, 2022 at 14:12

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.