# One of ten 74HC595 shift registers have wrong output state when clocking in data

I have a project that uses 10x 74HC595 shift registers to control a series of electromagnets (80x magnets in total), switched with transistors. My current situation is that when I pull the reset-pin of the '595 LOW and HIGH again, and thereafter clock the latch-pin, the outputs of all the '595s change to LOW, as expected. However, as soon as I start clocking bits in, one of the '595's output pins is also miraculously HIGH, whereafter it also shifts a HIGH bit as it would normally. The only difference is, it should be shifting only zeroes until the HIGH bit reaches that shift register and gets shifted through that particular IC. For some reason and by some means, that particular '595 gets a HIGH bit in its register and shifts that out. I have checked the serial input pin just before shifting, and there is certainly no HIGH bit being shifted in from the previous '595. So I have no idea where that particular HIGH bit is coming from.

Attached is a snipped from the schematic of how the '595 is connected. The outputs are connected to NMOS transistor gates for controlling the electromagnets. Below is a snippet from the code that controls the '595s:

void main(void)
{
int i;

/* Reset the shift register contents and latch new contents */
shiftReg_reset = LOW;
delayus(1);
shiftReg_reset = HIGH; //LOW-to-HIGH transition
delayus(1);
shiftReg_latch = HIGH; //Move new outputs (all zeroes) to latches
delayus(1);
shiftReg_latch = LOW; //HIGH-to-LOW transition
delayus(1);

shiftReg_out_en = LOW; /* Output enables '595s (active-LOW) */
shiftReg_reset = HIGH; /* Pull reset pins HIGH (active-LOW) */

for (i = 0[![enter image description here][1]][1]; i < 80; i++)
{
/* Set data pin */
shiftReg_data = HIGH;
delayus(1);

/* shift bit */
shiftReg_clock = HIGH;
delayus(1);
shiftReg_clock = LOW;

/* load '595 contents to output latches */
delayus(1);
shiftReg_latch = HIGH;
delayus(1);
shiftReg_latch = LOW;
delayms(250);
} /* for */
} /* main() */
`

I have no idea what is causing this behavior. As you can see from the code, the shift registers' outputs are all zeroes initially, but once the second bit is shifted, it seems like the same bit gets shifted from another '595 in the sequence, giving the idea that there are two sets of shift registers being interfaced to which output the same data, instead of doing it in a cascaded manner.

I have not yet connected any of the electromagnets to the circuit. For each transistor/electromagnet, I have also put in an LED to indicate the state of the shift register output. I am seeing the described phenomenon on the LEDs, so the phenomenon cannot be due to any effect caused by switching the electromagnets...

• Do you have an oscilloscope also? Oct 18, 2016 at 20:48
• did you use 220R or greater series with LEDs? Oct 18, 2016 at 22:16
• @Tony: Yes, I did. In fact, I am using 1k resistors in series with each LED (these are surface mount LEDs that are rather bright). Oct 18, 2016 at 23:17
• Debug with a scope or replace chip if it fails the datasheet specs. Beware of ESD Oct 18, 2016 at 23:37

I have known for decades that CMOS FF's and shift Registers alike can be toggled with EMI on the outputs feeding back into internal inputs.

So clean up your signals with common mode de-coupling, grounds, shields, add Ferrite CM chokes and differential ferrite beads and make all high current loops low EMI twisted pair shielded loops with clamp diodes and RC snubbers.

in some cases where RC driver filter latency , different on each pulse equal to the rise time or more can scatter synchronous glitches so they do not superimpose.

Remember that coil turn off pulse may cause high current or voltage fields due to L dI*dt

Just as twisting switched current wires together can reduce the pick up of radiated noise, twisting power wires together can reduce the amount of noise radiated by the wires in the first place. This is especially important with long power wires, such as those feeding switched inductive loads.

• Thanks for your comment and the advice regarding the cleaning of the signals. The electromagnets are not yet connected to the circuit. There are LEDs indicating the states of the shift registers' outputs, so it cannot be due to any effect from switching the electromagnets. I have updated the original post with this info. Oct 18, 2016 at 22:10
• Are there good ripple suppression caps and all wires twisted pairs? Do you have a logic probe ? Oct 18, 2016 at 22:13

I would guess that you might be getting crosstalk or other noise coupled onto some of your signal wires, perhaps due to a bad ground connection. Releasing lots of electromagnets simultaneously can easily cause ground bounce, which can appear as erroneous clocking events.

• Thanks for your comment. The electromagnets are not yet connected to the circuit. There are LEDs indicating the states of the shift registers' outputs, so it cannot be due to any effect from switching the electromagnets. I have updated the original post with this info. Oct 18, 2016 at 22:09

I've seen this before. Ten devices on the clock line togher with some "long" pcb track load the clock driver rounding off edges.

This, toghether with shift registers threshold and timing dispersion, scatters in time each register's shift action violating setpup and/or hold time constraints.
Net result is messing up the data stream when crossing from one IC to next one in the chain.

Probably the simpler clue is to use a stiffer clock driver but this may be a rather marginal cure. Different lot or brand shift register could not work again.

The hard'n safe way is to wire an RC low pass cell on each QH' to SER connection.
It's time constant should be greater then expexted timing scatter (a few hundreds ns should be okay) so to hold data to be shifted long enough for clock to do its job.

Obviously this time constant must also be much smaller then data rate to have correct bit ready for next shift, after one clock period.

• Thanks for your post, carloc. I have been able to solve the problem in the meantime. It seems that I had a bug in the embedded software that was driving the shift registers. Dec 19, 2016 at 9:39

I was able to solve the problem. It seems that there has been a bug in the embedded software that was interfacing with the shift registers, and that this was not a hardware problem, but rather a software issue that caused the problem.

• If you do not add details to your answer, this Q&A does not add much value to the site. Dec 19, 2016 at 10:10