2

I want drive a large number of LEDS from an Arduino Pro Mini using a number of TPIC6B595. I purchased these on ebay, perhaps a mistake.

Initially I connected two TPIC6B595 as I would connect 74HC595 (with the exception of taking account of how the open drain outputs work) to the SPI pins of an Arduino Mega (my test bench system) and tried sending an alternating bit pattern to the LEDs. No alternating LEDs. I checked SRCLR was Vcc and OE (G) was Gnd. I poked about with my scope (Rigol DS1102D) and SRCK, RCK and SERIN looked as expected. Suspiciously SEROUT (pin 18) of the first chip was permanently LOW. Note that this is all on a breadboard.

I have used the 74HC595 now many times and from time to time I have made stupid mistakes in wiring/software. These usually stand out on the scope like a sore toe. Not this time.

So I decided to simplify it all and clock some data into a single TPIC6B595 using a simple non-SPI sketch and see if anything comes out of the SEROUT.

Here are the connections to the TPIC6B595 and to the Mega:

1 Not connected,  20  Not connected, 
2 Vcc             19  Ground, 
3 Arduino pin 12  18  Not connected (except to scope when tested), 
4 Not connected   17  Not connected, 
5 Not connected   16  Not connected, 
6 Not connected   15  Not connected, 
7 Not connected   14  Not connected, 
8 Vcc             13  Arduino pin 11,  
9 Ground          12 Ground (See note 1), 
10 Ground         11  Ground.

The chip is bypassed by a 1uF electro across pins 2 and 10. Not ideal but the clock rates are low and it isn't unreliable, it just doesn't work at all. Note 1: I am not trying to test the transfer between the Shift Register and the output D flip-flops so RCK should be irrelevant. I just want to see data going in to SER IN , coming out on SER OUT.

Here's the Arduino code. It generates a slow clock and an alternating data bit every few clock cycles:

const int ser_clk = 11; // blue
const int ser_in  = 12; // white
byte data, count;

void setup()
{
  pinMode(ser_clk, OUTPUT);
  pinMode(ser_in,OUTPUT);
  
  digitalWrite(ser_clk, LOW);
  digitalWrite(ser_in, LOW);
  
  count = data = 0;
}

void loop()
{
  digitalWrite(ser_clk, HIGH);
  delay(1);
  digitalWrite(ser_clk, LOW);
  delay(1);
  
  count++;
  if (count >= 3)
     {
       count = 0;
       if (data == 0)
          {
            data = 1;
            digitalWrite(ser_in, HIGH);
          }
       else
          {
            data = 0;
            digitalWrite(ser_in, LOW);
          }
     }
}

Here's a screenshot of the wave-forms (photo of scope - sorry can't make UltraScope work):

Screenshot from Scope

The cyan trace is the "clock" from pin 11 of the Arduino feeding pin 13 (SRCLK) of the TPIC6B595. The yellow trace is the data from pin 12 of the Arduino feeding pin3 (SER IN) of the TPIC6B595. I am only looking to get the same data pattern out of SEROUT, pin 18 of the TPIC6B595 and this should do it. The clock is as slow as a wet week (see cursor) and even if I have bad set up and hold times and the wrong transitions the data is held for enough cycles for something to make it through surely?? Pin 18 is persistently and forever low. No screenshot - seems to be no point.

I bought several of these TPIC6B595. Tried 3 so far. All the same. Now I might have killed them with static. I am not using wrist straps, but I also don't believe I could have killed 3 of them.

As improbable as that is I think they are dead or duds, or is there something else wrong that is so obvious I cannot see it?

Regards, Fred.

  • > so RCK should be irrelevant. you probably want to read the datasheet to be sure of that, :) – dannyf Mar 11 '17 at 23:22
  • Shifting should still work even without latching. This is to allow daisy-chaining multiple devices and latching them only once all the devices have been charged. – Ignacio Vazquez-Abrams Mar 12 '17 at 0:36
  • Have you tried substituting them with a normal '595 and seeing if the desired behavior results? – Ignacio Vazquez-Abrams Mar 12 '17 at 0:38
  • 1
    fwiw all the "too cheap" components i've bought from ebay have worked fine... – dandavis Mar 12 '17 at 7:40
1

Thanks to all those who responded. I have a double embarrassment here as I have the answer. Firstly if you can answer your own question there is an argument it should never have been posted, more thought needed first. Sorry everyone. Secondly when the cause is ignoring well known good practice then it is even worse.

So when tying a pin to Vcc (in this case SRCLR) it is known bad practice to hard couple it to Vcc. A pull-up resistor is a much better method. In this case suitable pull-ups were in the next room and I could not be bothered so I just jumpered SRCLR to Vcc. After I had written the post I was staring at the breadboard and thought - I should not have really done that replaced the jumper with a 10K pullup to Vcc. Instantly the SEROUT pin of the TPIC6B595 came to life as it should have. Now I have taken this short-cut before and gotten away with it. But it seems not this time.

Subsequently I have a one chip version of the alternating LEDS running with the SPI interface.

As to the suggestion by dannyf about the datasheet, there is no doubt the datasheet is a good place place to go. Prior to developing my test sketch as per my original post I consulted the datasheet and if you look in Section 8, page 11 of the TI datasheet revised June 2015 there is a Functional Block Diagram. This block diagram clearly shows that the RCK signal is concerned only with the C2 column of D flip-flops which take the output from the shift register and latch it to the output FET through the output enable logic. RCK is independent of the process to clock data through the shift register, controlled by SRCLK. You will note my test did not exercise the transfer function it was just interested in getting data into the shift register and out again.

I stand by my assertion that for the serial shift register function and checking SEROUT, RCK is not relevant. Once you want to start data transfers from the shift register to the output register then it is different matter. No disagreement there. Having that timing wrong will lead to a mess of corrupted data.

Thanks again to all. This is solved and is a lesson to abide by good practice always.

Regards, Fred.

| improve this answer | |
  • > so I just jumpered SRCLR to Vcc. there may be something else at play. wiring srclr to vcc is perfectly acceptable -> the datasheet shows it, and the input block shows a serial resistor so in effect you have a pull-up resistor. puzzling to say the least. – dannyf Mar 12 '17 at 13:19

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.