TLC59711 flashing when using built-in SPI

[dzfan]

I purchased the Adafruit TLC59711 LED driver and ran the example sketch. Running the unmodified example works fine, but if I change the Adafruit_TLC59711 constructor to use the built-in SPI function instead of bit-banging, the sketch still runs, but the LEDs will flash off periodically (for periods on the order of 1-10 ms).

Code: Select all

//This line of code is used in the stock example
//Adafruit_TLC59711 tlc = Adafruit_TLC59711(NUM_TLC59711, clock, data);

//Using this constructor, which uses the hardware SPI protocol, causes LEDs to flicker.
Adafruit_TLC59711 tlc = Adafruit_TLC59711(NUM_TLC59711);

I have 4 RGB LEDs connected to the board. The colorWipe command seems to function correctly, but the RainbowCycle command causes colors to flit off and on.

Can someone help me understand why using the built-in SPI causes flickering? I'd like to use the built-in SPI because it's much faster (2 MHz vs. 70 kHZ).

Thanks for any advice you can offer.

Setup:
- I have 4 RGB LEDs connected to the board.
- Current limit resistor is 1.98k, which is a 25mA limit.
- Connections below (followed Adafruit tutorial http://learn.adafruit.com/tlc5947-tlc59 ... r-breakout
- DI -> Digital 11
- CI -> Digital 13
- VCC-> 3.3v
- GND -> GND
- V+ -> VIN
- No connections on Arduino pins 10 and 12 (SS and MISO).
- SPI is communicating at 2 MHz (clock divided by 8 )
- SPI mode 0 (default in SPI.cpp)

I scoped the SPI lines during a write and verified that the timing seems correct:

SPI transaction - Write and config bits (Built-in SPI)

Arduino - Adafruit example - write and config byte1 (built-in SPI).png (56.64 KiB) Viewed 1186 times

This is what it looks like with the stock example method, which is essentially bit-banging pins 11 and 13 manually:

SPI transaction - Write and config bits (Bit-banged SPI)

Arduino - Adafruit example - write and config byte1 (bit-bang) annotated.png (57.65 KiB) Viewed 1185 times

Note that the configuration register is defined as follows:
OUT_TMG = 1, EXT_GCK = 0, TMG_RST = 1, DSP_RPT = 1, BLANK = 0 --> 10110b
(see page 21 of the datasheet for more info about these register bits.)

As far as I can tell, the hardware SPI transaction looks identical whether the TLC59711's output is enabled or not. I've tried changing the TMG_RST to 0, and I get the same result.

Has anyone seen this before?

Here is a link to the datasheet http://www.ti.com/lit/ds/symlink/tlc59711.pdf.
The important data concerning communication protocol is on page 12 (SDTI and SCKI signals).

And here is the entire TLC59711test sketch example, just for the sake of completeness:

Code: Select all

/*************************************************** 
  This is an example for our Adafruit 12-channel PWM/LED driver

  Pick one up today in the adafruit shop!
  ------> http://www.adafruit.com/products/

  These drivers uses SPI to communicate, 2 pins are required to  
  interface: Data and Clock. The boards are chainable

  Adafruit invests time and resources providing this open source code, 
  please support Adafruit and open-source hardware by purchasing 
  products from Adafruit!

  Written by Limor Fried/Ladyada for Adafruit Industries.  
  BSD license, all text above must be included in any redistribution
 ****************************************************/

#include "Adafruit_TLC59711.h"
#include <SPI.h>

// How many boards do you have chained?
#define NUM_TLC59711 1

#define data   11
#define clock  13

//Adafruit_TLC59711 tlc = Adafruit_TLC59711(NUM_TLC59711, clock, data);
Adafruit_TLC59711 tlc = Adafruit_TLC59711(NUM_TLC59711);

void setup() {
  Serial.begin(9600);
  
  Serial.println("TLC59711 test");
  pinMode(10, OUTPUT);
  tlc.begin();
  tlc.write();
}

void loop() {
  colorWipe(65535, 0, 0, 100); // "Red" (depending on your LED wiring)
  delay(200);
  colorWipe(0, 65535, 0, 100); // "Green" (depending on your LED wiring)
  delay(200);
  colorWipe(0, 0, 65535, 100); // "Blue" (depending on your LED wiring)
  delay(200);
  
  rainbowCycle(5);
}


// Fill the dots one after the other with a color
void colorWipe(uint16_t r, uint16_t g, uint16_t b, uint8_t wait) {
  for(uint16_t i=0; i<8*NUM_TLC59711; i++) {
      tlc.setLED(i, r, g, b);
      tlc.write();
      delay(wait);
  }
}

// Slightly different, this makes the rainbow equally distributed throughout
void rainbowCycle(uint8_t wait) {
  uint32_t i, j;

  for(j=0; j<65535; j+=10) { // 1 cycle of all colors on wheel
    for(i=0; i < 4*NUM_TLC59711; i++) {
      Wheel(i, ((i * 65535 / (4*NUM_TLC59711)) + j) & 65535);
    }
    tlc.write();
    delay(wait);
  }
}

// Input a value 0 to 4095 to get a color value.
// The colours are a transition r - g - b - back to r.
void Wheel(uint8_t ledn, uint16_t WheelPos) {
  if(WheelPos < 21845) {
    tlc.setLED(ledn, 3*WheelPos, 65535 - 3*WheelPos, 0);
  } else if(WheelPos < 43690) {
    WheelPos -= 21845;
    tlc.setLED(ledn, 65535 - 3*WheelPos, 0, 3*WheelPos);
  } else {
    WheelPos -= 43690;
    tlc.setLED(ledn, 0, 3*WheelPos, 65535 - 3*WheelPos);
  }
}

[adafruit]

I dont know actually, we noticed it sometimes but could not figure out why - but we dont think its the speed. maybe its the mode? after much hacking, we were not sure so we used software SPI. its only 2 pins anyways :/

[dzfan]

I tried all four modes, no luck. Maybe it has something to do with the timing between bytes? I saw this timing diagram in a TI forum:
http://e2e.ti.com/cfs-file.ashx/__key/c ... timing.pdf

According to that graph, the time between bytes can be no longer than 8x the SCKI period. Using the default SCKI frequency of 2 MHz (SPI.setClockDivider(SPI_CLOCK_DIV8);), this is a period of 500 ns. So the next SCKI rising edge must come within (500 ns * 8 ) = 4 us. According to my measurements, the first rising edge of SCKI is 5.5 us after the last rising edge of the previous byte. So maybe the data latch is getting blanked?

Is there a way to alter the length of the idle time in the hardware SPI module? Or temporarily disable the receive period? I presume that pause is there for full-duplex capability.

[dzfan]

Going slower definitely didn't help. I just tested using SPI_CLOCK_DIV64, which corrects the idle timing (time between bytes), but the problem is actually worse. Now the TLC59711 actually freezes up and stops responding to commands, even though they're still being sent over SPI. Resetting the arduino doesn't help; you have to power cycle the TLC59711 to get it to respond again.

Using SPI_CLOCK_DIV64, the frequency is 250 kHz. I measured the clock period as 4 us, and the time between bytes was around 9 us, which is well within 8 * 4 us.

During the "freeze" of the TLC59711, it appears that each color channel that was at a non-zero value went to full brightness. Colors that were previously set to zero remain off. For example, if my desired setting was a dim green {0, 10000, 0}, what's actually outputted appears like {0, 65535, 0}.

[dzfan]

Maybe I missed something when I tried changing the SPI modes the first time. It appears that changing to SPI mode 3 did the trick.

I prefer using the built-in SPI over the software SPI because I could notice the lag in my button UI when I pressed several buttons in rapid succession. Using the hardware SPI made it more responsive.