I'm picking up a weird bug with my 74HC595 Shift Register's latch pin (Datasheet).

What do I want to do?

I'm essentially trying to visualise the shifting of the bits with the clock constantly running, and varying the serial input. I want to connect a LED to each output pin, and then connect my input clock (555 timer) to the latching pin (RCLK) and serial clock (SRCLK). As far as I understand the output LEDs should then show the state of the shift register, but delayed by one clock cycle, as mentioned in this datasheet:

If both clocks are connected together the input shift register is always one clock cycle ahead of the output register.

What is not working?

Connected the clocks together makes the shifting stop. Nothing shifts through. Not even in the shift registers, as I connected a LED to QH', and it never lights up.

The funny thing is that I could get it to work by unplugging the RCLKpin and letting it float. Then everything works perfectly, and I see my LEDs shifting. This is strange, as a change of state for RCLK is required for latching.

It even works if I place a switch on RCLK. Then I can see the latching only happening at the up and downward edges, as I expect.

But with the RCLKfloating shows the shifting bits perfectly.

My question:

  • Am I understanding how the 74HC595 chip works correctly? Is this intended behaviour?
  • Does the two input clocks need to be out of phase, as in the timing diagrams?
  • Could it just be EMI? It's built on a breadboard, but I put decoupling caps everywhere. Also, the speed I use never more than 2Hz, so I can't imagine that being the problem.

My setup:

My circuit is built on a breadboard, with the following schematic:

enter image description here

  • \$\begingroup\$ study the diagram on the first page of this ti.com/lit/ds/symlink/sn74hc595.pdf \$\endgroup\$ – jsotola May 5 '19 at 20:06
  • \$\begingroup\$ Thanks @jsotola, but I already have a few times. It shows there that the Qnoutputs only show what the storage register stores. And the storage register can only receive new values if the clock RCLK has an upward flank. So, leaving 'RCLK' floating should not update 'Qn'. :) \$\endgroup\$ – Hein Wessels May 5 '19 at 20:11
  • \$\begingroup\$ Data from the serial shift register is placed in the output register with a rising pulse on the RCLK pin. \$\endgroup\$ – G36 May 5 '19 at 20:12
  • \$\begingroup\$ Thanks @G36, but I am aware of that fact. That is why I'm confused why my circuit doesn't work if I connect both clocks together, and hence my question. \$\endgroup\$ – Hein Wessels May 5 '19 at 20:13
  • 2
    \$\begingroup\$ Are you sure there is only one clock driving both RCLK and SRCLK? From where does the clock come from? Also, this is a CMOS chip, inputs must not be left floating, or they will act funnily. The floating input might receive mains frequency hum and trigger to that. \$\endgroup\$ – Justme May 5 '19 at 20:21

Although I don't think a can give a full answer to the whole question, just my 2c. I ran into the same issue last weekend, namely sn74hc595n not doing anything if connecting clocks together.

First of all, leaving an input floating is not good. All datasheets say no input must be floating.

As to why your (and mine) 74hc595 did not work with the clocks connected together (even though the datasheet seems to imply it's fine), my current theory is that by connecting the clocks together we're potentially violating the timing requirement regarding SRCLK↑ before RCLK↑: according to the datasheet, it's required that if SRCLK rising edge precedes a RCLK rising edge, SRCLK should not come within 19ns (at 4.5V VCC) of RCLK. By raising both clock signals at the same time, they'll be within 19ns from each other, which breaks the requirement. Granted, if this is true then the datasheet is wrong in implying the clocks can be connected together (or maybe it means something different...). I've found other datasheets (like this toshiba 74hc595) which do not say the clocks can be connected together. So at this point, I'm doubting the accuracy of the TI datasheet. I haven't been able to confirm or rule out this.

| improve this answer | |
  • \$\begingroup\$ Nice first contribution, although I don't think it is a timing issue in this case. Most likely, the 555 is not outputting valid CMOS logic levels. \$\endgroup\$ – Caleb Reister Oct 8 '19 at 17:17
  • \$\begingroup\$ Yeah I'm not really sure either. But for what it's worth, I was running into the similar issues while driving the clocks from an arduino pin. \$\endgroup\$ – Sebastian Pueblas Oct 8 '19 at 17:20
  • \$\begingroup\$ Also my 74hc595 is a 10c a piece ic from AliExpress, so maybe it's not even original... \$\endgroup\$ – Sebastian Pueblas Oct 8 '19 at 17:23
  • \$\begingroup\$ That could be a problem. An Arduino should have no trouble driving the inputs of a '595, but decoupling can be an issue. \$\endgroup\$ – Caleb Reister Oct 8 '19 at 17:26
  • \$\begingroup\$ True. I was using a 1uf cap, that's what I had at home. I'll try with a 100nf if I can get ahold of one. Thanks for pointing that out. \$\endgroup\$ – Sebastian Pueblas Oct 8 '19 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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