Noise on floating 595 outputs?

[isg3]

I am trying to drive LEDs over SPI using SN74HC595 IC, powering it from 5V rail from arduino nano v3 (the one with CH340G). Conncections to 595 are as follows:
Vcc,GND - 5V, GND from nano, 100nF foil decoupling cap
serial input - MOSI
shift clock - SCK
latch clock - D3
output enable - directly to GND
reset - directly to Vcc
outputs A,B,C,D,E - LEDs, then connected to ground through resistors.
(so everything apart from outputs F, G, H and serial output H')

Basically works fine, but when I was measuring something with multimeter in voltage mode and when I touched usb port for ground reference, then 595 went haywire and turned all LEDs on. That was when powering through USB, but I can still replicate it using 9 volt battery albeit not as reliably. When I tap multimeter probes on the serial output pin of 595, LEDs turn on and off seemingly at random. As far as I can tell all inputs are tied to known potential, and as per application note unused outputs must be left floating, but then why I can make it malfunction just by touching the leads?
This is my code

#include <SPI.h>
#define LAT_CLK 3

void setup() {
  pinMode(LAT_CLK, OUTPUT);
  digitalWrite(LAT_CLK, LOW);
  SPI.begin();
}

byte stat = 0;
void loop() {
  ++stat;
  SPI.beginTransaction(SPISettings(1200000, MSBFIRST, SPI_MODE0));
  SPI.transfer(stat);
  digitalWrite(LAT_CLK, HIGH);
  delayMicroseconds(5);
  digitalWrite(LAT_CLK, LOW);
  SPI.endTransaction();
  delay(1000);
}

[PaulRB]

why I can make it malfunction just by touching the leads?

Two ways I can think of.

1. You have the meter in current measuring mode, so the probes can short-circuit anything they touch. You don't have a probe in the 10A socket do you? That would still cause shorts even if the meter it set to voltage measurement mode.

2. You have floating input(s) somewhere in the circuit. Even in voltage measurement mode, touching the probes to anything could cause unexpected stuff to happen.

Please post a schematic. Without that you make us blind. Hand drawn is ok.

[Wawa]

SPISettings(1200000

Likely not related, but that won't work on a classic 16Mhz Nano.
4Mhz is the default speed, can be switched to 8Mhz.

SPI.setClockDivider(SPI_CLOCK_DIV2); // default 4Mhz to 8Mhz

delayMicroseconds(5); // works AFAIK only in 4us intervals

Leo..

[PaulRB]

Wawa:
SPISettings(1200000

...that won't work on a classic 16Mhz Nano.

No, its fine. That frequency parameter sets the maximum clock speed for the bus, in this case 1.2MHz. The actual speed used is the highest that the Arduino is capable of that is less or equal to the parameter, so the actual speed on Nano should be 1MHz. (Max clock frequency for 74hc595 is 25MHz, although circuit wiring may limit that in practice.)

Wawa:
SPI.setClockDivider(SPI_CLOCK_DIV2);

setClockDivider() should not be used for new projects, and SPIsettings() is recommended for new projects. It's better suited to Arduinos based on AVR and non-AVR chips.

[PerryBebbington]

Hello isg3,

++Karma; // For posting your code correctly on your first post.

Noise on floating 595 outputs?

Outputs can't be floating, only inputs can float.

Without a schematic it is somewhere between difficult and impossible to help, please post a schematic.
How to post an image

Thank you.

[isg3]

Here is the schematic:

You have the meter in current measuring mode, so the probes can short-circuit anything they touch. You don't have a probe in the 10A socket do you? That would still cause shorts even if the meter it set to voltage measurement mode.

It was in voltage mode and wired for it. Glitch happend when I put first probe, so second one was not even connected to circuit yet.

You have floating input(s) somewhere in the circuit. Even in voltage measurement mode, touching the probes to anything could cause unexpected stuff to happen.

That's what I suspect as well. It's all wired on a breadboard, but connections read solid when checked by multimeter in continuity mode. I also checked if there is good ground connection, and 595 is not living on low inputs, but it seems to be all fine.

It occurred to me that it might be because of floating SS pin, switching SPI to slave mode. I added this line to setup, but issue still persists.

pinMode(10, OUTPUT); // hardware SPI SS pin as output

[PaulRB]

I can't seem problem with your schematic. Now I am thinking it could be unreliable connections in the breadboard. Even a slight pressure on the chip could cause a connection to momentarily break.

Maybe post a picture or two? Please check they are well lit and well focussed and every wire can be followed.

[isg3]

I attached photo of the circuit.

ven a slight pressure on the chip could cause a connection to momentarily break.

To rule this out, I connected serial output of 595 to unused part of breadboard and I could still replicate the issue by probing contacts inside the breadboard. Second probe not connected to anything, like before.

I don't know if this is related, but when testing this I have voltage meter in 20V range and for a moment it shows around 0.02V.

[PaulRB]

[PaulRB]

I can't see anything wrong there. I do rather hate those Dupont cables. You've checked every one?

If I get time later I will try to reproduce your circuit and test your code.

[isg3]

I measured resistance between every input pin, including Vcc and ground) of 595 and corresponding arduino pin and they are all below 3 ohms. I also tried two different 595 ICs (probably from the same batch) and two different nanos.

[Paul_B]

Those LEDs look uncomfortable!

[Grumpy_Mike]

100nF foil decoupling cap

These are useless for decoupling you need a ceramic capacitor. You might as well remove it as it is not doing any good. Learned this the hard way back in 1968 and it still crops up today.

What ever you are thinking it is doing it is not.

[isg3]

Good call, didn't know that. I replaced this film cap with a scavenged 100nF ceramic capacitor but it didn't help with the issue.

[Paul_B]

isg3:
Good call, didn't know that. I replaced this film cap with a scavenged 100nF ceramic capacitor but it didn't help with the issue.

No, we didn't expect it to, but just something you need to know about building digital circuits.

Lack of decoupling may cause erratic and sporadic malfunctions which will be even more difficult to figure than the present one.

[Grumpy_Mike]

Note that to be most effective the ceramic capacitor must be placed as close to the chip as possible, with the leads as short as possible, the original placement was miles away from doing much good.

[isg3]

I'm thinking maybe I just have bad chips. When I look up SN74HC595N on DigiKey, then only Texas Instruments pops up, but logo on my chips is not TI's. Maybe I'm missing something, but I could not find anything like this in manufacturer logo lists I found on the internet. The markings are 93DN9YX E4 SN74HC595N, and you can get a glimpse at the logo on the breadboard photo I gave. I have some of these in SMD with Toshiba logo on them. I'll try hacking them on my breadboard to see if they work better.

[Grumpy_Mike]

The markings are 93DN9YX E4

They are more likely to be date an batch codes.

I'm thinking maybe I just have bad chips

It is unlikely unless you bought them off eBay from the far east.

However, the data in the data sheets should be the same.

The logo looks like a flying bat, I have a vague idea I have seen it before but I can't see it on a search of manufacturers.

Here is an "enhanced blow up of it:

[Smajdalf]

Digital pin 10 must be output or tied HIGH when using HW SPI! It is Slave Select and when pulled low (such as by a noise when you connect the probe) the SPI interface turns into Slave mode assuming Arduino is selected as a Slave. Try using pin 10 as the latch pin instead of 3 - it should help.