TLC5940, TLC5941 and Arduino

The TI TLC59xx chip family are constant current LED drivers that have some pretty impressive stats.  I'm experimenting with the TLC5941 which has 16 constant current channels, 80mA sink capability per channel, 17v maximum LED voltage and 4096 PWM intensity levels per channel.  If you want to use it, here's an Eagle schematic and footprint to get you going: https://github.com/gandrewstone/tlc594x/blob/master/eagle/tlc594X.lbr

And here's a photo of 2 quad chip driver boards that I made.

Packing those features into such a small chip has created a device that has got some nasty traps that are not described in the datasheet (or hard to understand) and so it is easy for beginning hardware hackers to either fry a couple of chips or just give up in frustration.  If you are looking into using this chip, check out my experiences after the break.




TLC59XX Gotchas!

0. [EDIT] LED vs Chip Power

This is a terrible gotcha that is not in the data sheet.  Its so bad that I did not believe it until I verified it with TI support:  If the chip does not have power, but the LED lines HAVE POWER, you WILL BLOW OUT OR DEGRADE THE CHIP!  Since the LED lines can take a much higher voltage than the chip itself, it is very common to have separate power supplying the LEDs and the TLC chips.  If you do this, you must make sure that the LED circuits are never powered if the chip is unpowered.  You can enforce this with a high-side driver chip.  I have had good luck with connecting a driver chip's "enable" line directly to the TLC (and Arduino's) VIN.  However, there could clearly be some transient issues in doing so as this means that the TLC gains power exactly when the LED lines are also powered.  A better solution is to connect the high side driver's enable line to an Arduino digital output to be turned on only after the TLC has been initialized in software.

1. Heat dissipation

To drive a LED with a constant current chip, you hook the + side of the LED up to an input voltage, and the - side (cathode) to the chip, which is connected to ground.  This means that the full input voltage must be dissipated in the LED + the chip, and since the LED basically dissipates a constant voltage, the TLC59xx chip dissipates the rest as heat.  At 80mA (or even 20mA with the small packages provided), you can't just provide 12v for a single 3v LED.  Do that and you'll let the smoke out :-) essentially instantly.  Instead, you need to provide a voltage that is about 1.5v above what the LED uses.

This issue is true for all multi-channel constant current LED drivers but is amplified by the high current and small size of the TLC family.

The problem gets worse when you are using multicolored LEDs, since red LEDs drop less voltage then blue.  To really drive your LEDs at the maximum current you may need to drop the voltages to all the red LEDs further then the green and blue channels.  It would likely be the most efficient to use a separate switched power supply, but a quick and cheap way to do it is to make lower voltage power source by putting a couple of 3amp diodes (they .7 volts) in series/parallel to meet your desired voltage drop and current requirements.

2. Disconnected power draw

Each channel in the TLC594x chip drives a transistor using a feedback loop to make it meet a particular current requirement.  If a channel is disconnected, the feedback loop will fully drive the transistor.  If most of the channels are disconnected (quite common in a testing environment if not in production), this will end up pulling quite a bit of power from the chip's 3.3 or 5v supply.  This can heat up the chip and cause power supply issues.  You can read more about this issue on TI's forum: "TLC5940 with no load", and see one user's estimate of power consumption.

In fact, I feel that there may be a bug in the chip that can magnify the problem. I have daisy-chained 4 or more chips, turned every channel on with no LEDs and have felt 1 chip that was burning hot while the others were just warm.

3. XERR Issues

The XERR line is intended to indicate both over-temperature conditions and whether LEDs are in the "open" state (burnt out or disconnected).  I have noticed that at lower voltages and higher power, the XERR line triggers whenever a LED is turned on.  This effect diminishes dramatically, but does not completely disappear, when "decoupling" capacitors (1uF and 100+uF) are added between the LED supply and GND.  So to get a clean XERR, you must supply the LEDs with higher voltage then is strictly necessary.
Essentially, the chip is triggering XERR prematurely -- probably because at the instant it turns on an LED, wire inductance causes a dip in the LED supply voltage.  This dip is not visually noticeable so would be acceptable if it did not affect XERR.

XERR is also used to indicate over temperature issues.  XERR reports on over temperature when the BLANK line is asserted (so all LEDs are off).  However, if XERR is asserted due to LEDs seeming "open" then it does not relax right away.  Check out this scope capture, showing open LEDs with no temperature condition.  The blue trace is the BLANK, the yellow is XERR (low is asserted, high is relaxed).:

As you can see the XERR line is not released until about 400ns after BLANK.  This gap means that to use XERR for over temperature detection, your BLANK signal must be high for longer.

A long BLANK time is not desirable because it directly affects the maximum duty cycle (the TLC59xx family can't do a 100% duty cycle -- the BLANK signal must be asserted to reset the PWM counter, and it turns off all the LEDs).


4. Benchtop power supply interactions

Lack of proper decoupling put my benchtop supply (which was attempting to deliver a constant voltage) into an unstable feedback loop with the TLC's constant current circuitry.  While set for 5v, the supply was reporting voltages up to 37v, and this was likely the cause of a few burned out chips.  The easiest fix is to simply put 100 to 1000uF caps between your power supply's Vcc and GND.  This is of course something you'd always do in a finished product, but is pretty easy to forget to do on a breadboard.  I haven't seen this when using any other LED driver chips.


5. Flickering caused by lack of electron supply (transients on GND).

Driving data into the TLC was causing LEDs that should be off to briefly flash on and LEDs that were on to flicker.  I realized that the problem is that the LED GND and the logic GND are the same, so the energy stored in the suggested-by-datasheet .1uF logic decoupling capacitors is easily consumed by high-power LED drivers.  This causes GND to temporarily float and therefore results in bad interpretation of data (and other issues).

The answer is to use significant capacitive decoupling.  To solve the issue, I used .1uF, 4.7uF (ceramic), and 100uF (electrolytic) in parallel for groups of 4 chips.  But this may be overkill, I did not experiment.


6. Data integrity when daisy-chaining chips

I have read theoretical postings suggesting hundreds of daisy-chained TLCs.  But in my experience, even in a very tight physical space you'll start topping out between 10 and 20 chips.  Beyond this amount, the SCLK signal's slope will degrade, causing the data line to be sampled at the wrong time.  For me, this occurs when using SPI for transfer.  Of course, you could solve this to some degree by writing a very slow bit-bang that would drive the data line, wait, then drive SCLK high.

But doing this dramatically reduces the maximum refresh rate (both by adding chips to the chain and by slowing down the data clock speed), and means the microprocessor is spending a lot more time running the LEDs.


7. Daisy-chaining and brightness reference current (Iref)

When daisy-chaining, it would be convenient if a single resistor could be used to set the LED current.  This is especially true if you are using a potentiometer to allow current to be adjusted on the fly.  But, simply connecting Irefs and feeding them through a resistor does not work for the same reason it is not recommended for LEDs.  Slight manufacturing differences will cause one device to essentially dominate the current feed and the other devices will turn off.  The end result burns out your chips.  However, the problem can be solved relatively easily.  First, you need to put each line through its own 470ohm resistor.  Why 470?  That's the nearest "normal" resistor value to the 480ohm resistor needed to select 80mA current (see figure 3 "Reference Resistor vs Output Current" in the TLC5941 datasheet).

Then connect those resistors to a single pot to GND.  Just to be extra sure, put a low value capacitor across the pot.  This will stop any "ringing" that might occur.  Finally, you might not be able to find a pot in the required range (0 to about 2.5k to 3.5k, see figure 3) so you can put a resistor in parallel with the pot to modify its effective value.  I used a 5k pot and a 2.5k resistor.  The following schematic may make my description more clear!

And that's it!  Sure, the TLC family may be a bit more trouble then the previous generation of LED drivers, however, the additional features are worth it.  And you'll become a better engineer using them :-).  Good Luck!!!

...follow this blog or check back in a few weeks for info about the software side...