Hi,

I have been using the 74HC595 8 bit shift register to control LED's and other IC's. When shifting out 8 bits the register works perfectly, however, when I try to cascade them in series so that I can control, say 16 lines, the output of the first register going into the next isn't what's supposed to be. Specifically, when shifting out say, 1101 it would shift out only 111, it skips the 0. However, if I shift out 11001, it would shift out 1101.

In order to make sure that none of my other components are responsible I have been looking at a circuit that contains "only" a single 595, no other components (except a lm7805). I have been looking at the 4 control lines and one output line.

Using this symbolism http://www.onsemi.com/pub_link/Collateral/MC74HC595A-D.PDF I tied OE to ground. Output lines Qa-Qh are open. I'm looking at SQh, latch, shift clock, reset and A (din). As I said when shifting only 8 bits to outputs Qa-Qh it works fine, so my clocking must be fine. Anyway, here is the problem.

I reset the 595, then I start clocking in data into the shift register at A on each + edge. After 8 clock cycles, the data starts appearing at the SQh output. From the data sheet you'd expect that whatever has been at A will appear 8 cycles later at SQh, in order. But what happens, say I clock in 10101010 11111111 I actually observe at SQh 11110000. If I clock in 1001001001.... I'll get 10101... Somehow, the zeros are lost. On the other hand, if I clock in 1000 0000 00..... I will get the correct output

The interesting thing is that after trying many different input patterns, I still couldn't predict what the output will be, nonetheless, for a given input pattern, the output pattern at SQh would always be the same. I tried clocking at 9600, I even tried doing it manually from my PC at very low speed. I tried the chip from both ON and fairchild semi, but the output would always be the same but unpredictable.

I have tried as input to the 595 different IC's. I have tried the ftdi ft232R as well NI's DAQ.

I am wondering if anyone ever cascaded these chips and ever got it to work. At this point I'm thinking that maybe the chip itself is bad, although I tried at least 4.

I would really appreciate any suggestions as to what could be wrong or a simillar chip that has been tried and works, although the pinout would have to be similar.

Thanks,
Matt

 

Using this symbolism http://www.onsemi.com/pub_link/Collateral/MC74HC595A-D.PDF I tied OE to ground. Output lines Qa-Qh are open. I'm looking at SQh, latch, shift clock, reset and A (din). As I said when shifting only 8 bits to outputs Qa-Qh it works fine, so my clocking must be fine. Anyway, here is the problem.

Shows us a sketch of how you have connected the various signals to the second 595.

Are you saying the first bit does not appear at the SQh output after eight clocking? If so, then how can Qh output level of the first 595 be correct?

The 595 has been around for ages and people had cascaded dozens of them without a problem. Here is one example.

 

I attached a schematic of the two connected. But, at the moment I'm looking at a single 595 and its output at SQh.

And you're right, if I clocked out 8 bits Qa-Qh are fine, however, if I shifted 9 or more bits than Qh will be screwed up as well when I latch it. But only Qh, not the rest. Does that maybe mean that there is some memory effects at SQh/Qh? It's mostly that if there is a zero between two ones, that zero will be skipped. I can draw a timing diagram if you want.

Most people, I think, don't use the 595 for more than 8 bits, so is it possible that no one noticed it, but this particular batch of 595 is bad?

I also noticed something else that is not according to spec, according to spec, reset shouldn't affect the latch. However, say all outputs are latched to 1, if I than reset the shift register, all the outputs go back to 0. And that is without me clocking anything, just a reset.

Thanks,

 

First off, I've never used reset, and have always tied it high to V+. Have you tried that?

Is there a problem with the code? Here's a simple 16 bit shiftout from a microcontroller perspective, haven't messed from the PC side at all. In this case, led's were tied to the outputs, and not checked at SQh. Have you tried verifying at the outputs, after latching? Maybe its a data variable not be dimensioned correctly, in microcontroller lingo, this would be a data word (16 bit).

Sub Shiftout (Dataout as word)#NR

Latch = 0                'Start output data latch
    For Clocks = 1 to 16
      Clock = 0            'Shift register clocked
      Data = Dataout.0
      Clock = 1
      Rotate Dataout Right Simple
    Next Clocks
Latch = 1                                
                    
End Sub

 

That is pretty much how my code is. And since I was able to control 8 bits properly, that is I could set any of the first 8 outputs as I wished I was pretty sure that my timing is correct.

As for the reset, I haven't tried it without resetting, but I cannot see how that would cause it since I sometimes waited a few seconds after the reset before clocking data. However, I'll try it.

Also, initially I didn't look at SQh but I did latch the outputs of both 595s, after seeing that the second 595's output was wrong, I disconnected the second and looked only at SQh. If you look at the data sheet you'll see that SQh must be identical to what was at A (DIN) 8 cycles previously. Also, since both 595s get identical signals from the micro, the only difference being that the first 595 gets its data from the micro while the second from SQh, the data at SQh must be just 8 cycles delayed otherwise you'd 16 cycles won't work. But as I said, I initially tried it without looking at SQh but at the outputs and they were wrong.

Which 595s did you use? I tried from both ON and fairchild semiconductor.


Here is my code. I was using a FT232R so there are 8 lines of control, just look at the rightmost 4 - they were connected to the 595, the others (sclkA, dinA, outA, sclkM) are not used. The array output to which I'm writing will then be output at 9600 baud. In case you'll say to check the FT232R, I also output the data manually in LabView using their DAQ device with the same results. That's how I was able to play with each 595 line.

Also, valveData contains the data to be shifted out, and as you can see I only used 6/8 of the 595 outputs.

int i= 0;
int j= 0;
output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(0<<resetV);
output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
for(;j<numValves;){
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|((j<numValves?valveData[j]:0)<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
    ++j;
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(0<<sclkV)|(0<<latchV)|(1<<resetV);
    output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
}
output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);
output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(1<<latchV)|(1<<resetV);
output[i++]= (sclkAV<<sclkA)|(dinAV<<dinA)|(outAV<<outA)|(sclkMV<<sclkM)|(0<<dinV)|(1<<sclkV)|(0<<latchV)|(1<<resetV);

 

I will assume you've got each chip bypassed between the Vcc & GND pins as close to the ICs as possible?

 

I will assume you've got each chip bypassed between the Vcc & GND pins as close to the ICs as possible?

I'm not sure what you mean by that. Both IC's are on a breadboard right now. Do you mean if I have a capacitor between them? Actually I don't, but there is a capacitor at the output of the voltage regulator, although it isn't close to the IC. Would that account for these things?

 

I'm not sure what you mean by that. Both IC's are on a breadboard right now. Do you mean if I have a capacitor between them? Actually I don't, but there is a capacitor at the output of the voltage regulator, although it isn't close to the IC. Would that account for these things?

That sure will, if a digital IC (especially the older ones) aren't bypassed they can do crazy things.

You need to place 0.1 uF capacitors as close as possible to the ICs to decouple the spikes coming out of the things and onto the power supply lines.

 

mylee;

Which 595s did you use? I tried from both ON and fairchild semiconductor.

Shouldn't make any difference, but have used motorola, and bought some ON semi last time because they were cheaper.

I would set it up with a micro, tie up the reset, and just check the outputs. In other words, reduce to the challenge to the least common denominator. Once that is proved, then try over the serial port.

I don't like the way the FT235R statements look. Shouldn't the clock appear both before, then after the data is presented to the '595? Same with latch. I think it's a timing thing.

 

I'll try the cap tomorrow and see if that helps.

@nickelflipper Although I have a AVR micro, I have only ever programmed in assembly, and it would take me too much time to set one up, especially since I program mine with the FT232R using bit bang mode which means I cannot debug it easily. Every time I want to change something I have to reprogram the micro, I cannot quickly test it. Also, I'm in the middle of the semester so I don't have that much time to do this.

However, I don't know why you say that the clock has to be presented before/after the data. If you look on page 6 of the data sheet in my first post, it says that to shift in data, the shift clock has to present a + edge. In my code, the clock goes low and presents the data, then the clock goes high. Also, remember that the data is written by the FT232R starting from index 0 in the array and upwards.

In your micro code it appears to do the same thing - clock goes low, data is presented and then clock goes high - unless I don't understand it, since I don't know what the statement "Rotate Dataout Right Simple" does.

Thanks for the help
Matt

 

mylee00:
The Rotate Dataout Right Simple is just bit shifting the data value right each time thru the loop.

Too bad about the micro setup, and sorry for misinterpreting your code. Out of ideas for now, so best of luck. Hopefully that cap will do it for you.

 

to mylee00:

I also noticed something else that is not according to spec, according to spec, reset shouldn't affect the latch. However, say all outputs are latched to 1, if I than reset the shift register, all the outputs go back to 0. And that is without me clocking anything, just a reset.

According to the datasheet, when the 595 is under reset, it is still possible to latch the working registers content into the output registers. Thus the reset action would "reset" the working registers to "0" and a positive level change on the LATCH pin(somehow, even if not intended) will then latch these "0"s into the output registers so you got all zero on outputs.

If you get this even if you have hold the LATCH pin LOW physically(by a wire) then it would be interesting to know about. Don't rely on a port to hold the level LOW as there can be glitches which you don't know about when you manuplate the port pin logic level.

Use the following circuit as shift clocking source to quickly and easily check out the operation of your 595 hardware connection. The component are not critical. Just make sure one resistor is 50 times the value of the other. Any NAND gates will also work.

Two button presses equals to one complete clock. You can change the DATA input logic of the 595 by a dip switch at will.

This will tell you if the hardware or the signal from the MCU is at fault.

 

Ok, so I tried out a few things, but no luck.

I tried not using the reset, i.e. short it to VCC, but it didn't help.

I added a 0.1uF cap right at the VCC pin and when that didn't work I added a 10uF followed by the 0.1uF but that didn't help either. When I looked at the power signal in a o'scope there was noise of +/-50mV, but it was otherwise stable. I did see some waves from time to time when I clocked signals, but it was below 50mV. Actually, since the VCC and GND pins are in two opposite sides of the chip, I placed the cap between the VCC pin and GND, but not "the" GND pin.

@eblc1388: The latch-reset effect doesn't occur when I test the 595 by itself. It only occurs when it's part of a larger circuit and is driving LEDs and other things. I'll have to play around a bit with my connectors to be able to tie the latch clock to GND in that circuit.

I'm pretty confidant that the signals are correct, because I tested the 595 with two different control devices. Also, since I'm able to control the first 8 bits, i.e. the first 595's 8 outputs, my signals must be correct otherwise that wouldn't work either, instead the problem only shows up when I try to clock out more than 8 bits. I don't actually have the components to build the circuit you've shown in order to control the lines, but if all else fails I'll try that. Currently I'm using this http://sine.ni.com/nips/cds/view/p/lang/en/nid/201986 to drive the 595.

I also looked at the signals using my o'scope. Since I have only one scope, I had to do it twice. Channel 2 is always the shift clock and in the first graph (DIN.BMP) channel 1 is the input data, while in the second (SQh.BMP) it's SQh. As you can see, the input is clocked in as alternating 1's and 0's while at SQh it's not at all like that.

I noticed that the output pattern at SQh for a given input changed when I connected the scope to different places. That is, although the output still didn't make sense, the pattern that it output varied depending on which pin the scope was monitoring. This really shows that SQh is very sensitive to something, although I'm not sure what.

Is there anything else besides the signals that could be wrong? At which point should I start suspecting the IC themselves? Or maybe I'm missing something very basic, although I cannot fathom what that would be? I'm thinking of taking my whole setup and testing it in another persons lab in my univ. with their power supply and everything, since maybe there is a Flying Spaghetti Monster in my lab.

Thanks,
Matt

 

Is there anything else besides the signals that could be wrong?

The output of the SQh is wrong because it changes on a falling edge of the shift clock. It should never do that alone. The most probable cause is your shift clock signal is not clean and have glitches, or glitches on other control lines such as reset or latch clock or the power supply.

The changing of SQh upon different connection of the CRO probe also indicate problem with your setup. Have you checked the common connection between 595 and signal source? Try adding another common connection.

The only way to be sure is to pulse the 595 in a manually controlled way using the device I posted earlier and confirm its hardware function first. You really need to build that to satisfy yourself that the 595 is *NOT* at fault. Its hard to believe that it is not possible to get the required component inside a lab of an university.

At which point should I start suspecting the IC themselves?

I would like to ask you if you have ever won the lottery TWICE? Not once but twice. Finding faults in ICs with years of established usage is about that odds.

Or maybe I'm missing something very basic, although I cannot fathom what that would be?

I'm sure it is. Please keep us informed as your post might be very useful to other users that have the same encounter.

 

I got a bit busy but I did make some progress. I took the 595 over to another lab and tested it there and it worked fine. It turned out the it was the signal source that caused the problem. That is, that lab had another USB device to generate signals - the USB 1208LS http://www.microdaq.com/measurement_computing/12bit_daq/usb-1208ls-daq.php and using that the 595 worked perfectly.

So I borrowed the 1208LS and tried in my lab with my old original circuit and it also worked perfectly. This means that I won't have to build the above circuit because we know that the 595 works. I guess I'm not winning the lottery

The question now is why does the 595 not work with the USB 6008. Both the 6008 and 1208 are connected to the same computer, in fact I had the 6008 connected to DIN gate while at the same time I used the 1208 connected to the shift clock gate to clock out the signals and it worked perfectly, it only didn't work when the 6008 was the one to clock in the data. It's important for me to figure this out because I'm using the FT232R to generate the signals to the 595 in my other circuits and I'm having the same problem. I cannot switch from the FT232R now.

I don't think it's noise because the first 8 bits works fine both in the 6008 and ft232r, it doesn't work only when clocking out more than 8 bits. Also, in the scope there doesn't appear to be any noise in the signal. I tried placing some 18pF capacitors on the line and it didn't help any.

I don't know enough about CMOS to be able to figure out from the data sheets if there is some incompatibility between the 595 and the 6008/ft232r. Can someone please look at their data sheets to see if there is some reason why they wouldn't work together? The data sheets are listed below. I know that the 6008 has a 4.7k pull up, the 1208 has a 47k pull up and the ft232r doesn't have any pull-up. I'm also attaching a pic of both the 6008 and 1208 going from high to low.

Here are the data sheets for the ICs
74HC595: http://www.nxp.com/documents/data_sheet/74HC_HCT595.pdf
USB 6008: http://www.ni.com/pdf/manuals/371303l.pdf
USB 1208LS http://www.microdaq.com/measurement_computing/documents/usb-1208ls-usermanual.pdf
FTDI FT232R: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf

So the question is, which of the specs of the 595 or 6008 am I violating when they are connected together and if it's just noise, why don't I see it in the scope and how can I fix it?

Thanks for the help,
Matt

 

Do a capture of the 595 data pin, shift clock and latch clock signals from start to finish on a 16 bits data transfer using a logic analyser.

The timing of various signals will then tell you exactly why it doesn't work.

 

I don't have a logic analyzer and I don't know anyone that has one. If you look on the scope image from the previous posts, the transaction does looks fine. I was wondering, if I wanted to put some kind of buffer between my signal and the 595 what would I use? I tried using the output of a n channel mosfet but that didn't help.

Thanks

 

I got busy with classes so I didn't have time to solve it until now when classes are over.

I tried fixing it with a series resistor and filtering the signal but that didn't help. In the end what fixed it was placing a buffer (schmitt triggered 74HC7541N) between the source (ft232) and 595. As I understand now, there must have been some kind of mismatched impedance between them that was fixed by the buffer. The effect of this was probably to distort the clock signal or something.

Thanks for all the help, especially eblc1388.

Matt