Negative voltage on 74HC595 boot?

Other Hardware General Electronics
1

Hi all!

I'm doing a project where I use a 74HC595 output shift register. I've done a simple LED circuit (reference https://www.arduino.cc/en/tutorial/ShiftOut, and I corrected the decoupling capacitor issue) to test it and also adapted it to control some relay modules (the relays are opto-isolated, no excess draw!). I'm also controlling the output enable via the Arduino to deal with the boot-up but something strange still happens: when I boot the circuit the output pins' voltage dips below ground for about 150us, after that rising to the expected 5V (measured with a cheap oscilloscope but it's there).

I didn't notice it at first with the LEDs since, well, they're diodes, but sure enough the relay circuit uses inverted logic so I was able to see some blinking in their LEDs. When I inverted the LED circuit (cathodes to 595 outputs), the LEDs also blinked for a split second, confirming the oscilloscope observation.

Now my first set of questions would be: why does this happen, is it normal and unavoidable, or am I doing something wrong?

More pragmatically, the final circuit will use the 595 outputs to control a set of NPN transistors, which in turn control other devices not relevant for the question. So my second set of questions is whether this very short "blink" would produce any undesirable effect on the switching transistors (analysing gate currents and voltages is something newish to me); and if a way to correct the problem would be to add diodes to the 595 outputs to prevent this. Might be overkill, but I'm also trying to learn the pros and cons of each approach, and if I can get a "perfect" output the better.

Thanks!

2

Please fix your broken link. It's because nobody bothers (or understands that it's important) to connect the 595 reset line MR to the system Reset line. So the chip powers up in a random state, which isn't corrected until the code has time to get to that.

3

aarg:
Please fix your broken link. It's because nobody bothers (or understands that it's important) to connect the 595 reset line MR to the system Reset line. So the chip powers up in a random state, which isn't corrected until the code has time to get to that.

I thought the OE would prevent that, but I will try to experiment with MR. You mean the Arduino reset pin?

4

guilhermept:
I thought the OE would prevent that, but I will try to experiment with MR. You mean the Arduino reset pin?

Why would you think that? OE is output enable, and in the experiment it's permanently grounded. Yes I mean the Arduino reset pin. The idea is to reset the 595 at the same time the Arduino is reset.

Actually, they told you about this in the tutorial:

The one flaw of this set up is that you end up with the lights turning on to their last state or something arbitrary every time you first power up the circuit before the program starts to run. You can get around this by controlling the MR and OE pins from your Arduino board too

The "gotcha" is that the output pins are in a high impedance state when MR is active, so your transistor drivers must be designed to be "off" when this is the case.

5

aarg:
Why would you think that? OE is output enable, and in the experiment it's permanently grounded. Yes I mean the Arduino reset pin. The idea is to reset the 595 at the same time the Arduino is reset.

Actually, they told you about this in the tutorial:The "gotcha" is that the output pins are in a high impedance state when MR is active, so your transistor drivers must be designed to be "off" when this is the case.

I thought having the output "disabled" made the pins to always be OFF, I control it programatically as I said in the first post. Anyway, I have tried different approaches with the MR pin to no avail:

Am I missing something?

6

Please post photo of the circuit and the scope trace. How you can get negative voltage for so long? Maybe a wiring error? I doubt any pin manipulation is able to fix this.

7

Unless you put a pull-up resistor on the OE pin, it is in undefined state until the Arduino gets around to setting it. That means the outputs may very well be active the moment the project is powered up. After that you can have the Arduino drive the OE pin low when the outputs are ready to be enabled.

8

It seems that by adding a pull-up on the latch the issue is fixed (as seen here: [solved] shift register 74hc595 - LEDs and Multiplexing - Arduino Forum)...

After that, it seems that connecting MR to VCC or RESET is the same. Nevertheless, I'd like to know if something like this is useful and whether I should add it versus tying MR to VCC or RESET. Particularly if any approach might give some problemas down the line...

Below is the current circuit, the only change from the original post being the latch pull-up. I'd appreciate a lot if you could tell me if there's some other flaw in the design, whether that MR capacitor mentioned above is recommended, and otherwise any suggestions to improve it (with the final circuit being used to control transistors instead of LEDs, but I'm looking about improvements regarding the 595 usage per se).

1072×1020 14.8 KB

9

Unfortunately the problem still persists. The pull up on the latch seems to have helped, but it still happens sometimes... So something is still not ok in the circuit probably.

Here is the trace:

850×616 757 KB

It's visible to the naked eye, since all the LEDs that are supposed to be off blink very briefly.

10

Post the code you are running.
I would make these connections:
D13 (SCK) to SRCLK (11)
D11 (MOSI) to Ser Data In (14)
D10 (SS) to RCK (12).

Then in your sketch, use SPI.transfer to load it up:

At the top of the sketch
# include <SPI.h>
const byte ssPin = 10;
byte x;
byte dataArray[] = {0x00, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0xff,};

In setup()
pinMode (ssPin, OUTPUT);
SPI.begin();

In loop() (or in setup(), to run it just once), a simple test pattern to check all the LEDs:

for (x = 0; x < 10; x=x+1){
digitalWrite (ssPin, LOW);
SPI.transfer (dataArray[x]);
digitalWrite (ssPin, HIGH); // '595 outputs change on this rising edge
delay(500); //dumb delay just to see the lights
}
11

And add a 0.1uF cap on the '595 VCC pin to Gnd to help with stability.

12

Again: I believe this is not a digital problem. No amount of pull-ups and software manipulation can explain or solve this. HOW DO YOU GET NEGATIVE VOLTAGE???? Are you using negative voltage on other parts of your circuit? Is it somehow connected to the '595? Where exactly are you measuring with the scope? When does the glitch happen - at power up or any reset? So many questions, so few answers.
You should be probing around the circuit as crazy to find the problem, single trace is not enough. Is there something else strange with the signals? Is '595 GND following Arduino/power source/LEDs GND? What about Vcc?

13

guilhermept:
Unfortunately the problem still persists. The pull up on the latch seems to have helped, but it still happens sometimes... So something is still not ok in the circuit probably.

Here is the trace:

850×616 757 KB

It's visible to the naked eye, since all the LEDs that are supposed to be off blink very briefly.

Where did you put the probe and its gnd clip on your circuit?
Is the middle of the graticule gnd?
Thanks.. Tom.. :slight_smile:

14

CrossRoads:
Post the code you are running.
I would make these connections:
D13 (SCK) to SRCLK (11)
D11 (MOSI) to Ser Data In (14)
D10 (SS) to RCK (12).

Then in your sketch, use SPI.transfer to load it up:

At the top of the sketch

include <SPI.h>

const byte ssPin = 10;
byte x;
byte dataArray[] = {0x00, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0xff,};

In setup()
pinMode (ssPin, OUTPUT);
SPI.begin();

In loop() (or in setup(), to run it just once), a simple test pattern to check all the LEDs:

for (x = 0; x < 10; x=x+1){
digitalWrite (ssPin, LOW);
SPI.transfer (dataArray[x]);
digitalWrite (ssPin, HIGH); // '595 outputs change on this rising edge
delay(500); //dumb delay just to see the lights
}

It seems that with the new code it's working fine! Previously I was using the binary counter from the shift out Arduino example, with the output enable control I put here as well. Here's the code I'm currently running:

# include <SPI.h>
const byte ssPin = 10;
byte x;
byte dataArray[] = {0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0xff, 0x00,};
int outputEnablePin = 9;

void setup() {
  pinMode (ssPin, OUTPUT);
  SPI.begin();  
  digitalWrite(outputEnablePin, 1);
  pinMode(outputEnablePin, OUTPUT);

  // init as all 1 (negative logic)
  digitalWrite (ssPin, LOW);
  SPI.transfer (0xFF);
  digitalWrite (ssPin, HIGH);

  digitalWrite(outputEnablePin, 0);
}

void loop() {
  for (x = 0; x < 10; x=x+1){
    digitalWrite (ssPin, LOW);
    SPI.transfer (~dataArray[x]);
    digitalWrite (ssPin, HIGH); // '595 outputs change on this rising edge
    delay(500); //dumb delay just to see the lights
  }
}

To answer other questions, I already had two caps for decoupling. All ground and VCC comes from the Arduino, no other circuits involved. I connected the scope black probe to the Arduino GND, and the red probe to different 595 outputs (tried different ones, all with the same problem). However, the problem was visible to the naked eye anyway, I'm not sure what else I could probe to find the source of the problem.

But given that the code solved it, probably something to do with a delay by using non-SPI pins? Had never used them before really.

15

The problem was solved or hidden?

May best guess is you don't have Vcc or GND connected and you are phantom powering the 595 via the input pins. This way the decoupling caps can generate negative voltage.

16

Smajdalf:
The problem was solved or hidden?

May best guess is you don't have Vcc or GND connected and you are phantom powering the 595 via the input pins. This way the decoupling caps can generate negative voltage.

Maybe some jumper's faulty... But if that's the case, as long as the schematic is correct, there should be no problem when I solder the circuit.

17

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.