Wednesday, May 30, 2012

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:

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...


  1. Issue number 6 is not a show stopper. Every digital output pin can only drive a certain number of digital input pins, called the "maximum fanout"--typically around 10 or 20. If you want to drive more than 10 inputs from one output, you have to add non-inverting buffers like the 74HC244. Then the Arduino can drive 10 buffers, and each buffer can drive 10 TLCs, and you can drive 100 chips at once.

    1. The issue is not fanout, as such. Fanout refers to the total ability of the output gate to drive current into the others. The issue with driving a long chain of TLCs from a single chip is that of degradation of the clock signal as it travels a longer distance, and the timing skew created by passing the serial data through a larger number of chips.

    2. It is hard to know the exact problem and I think it depends on your physical topology. In my case, 4 chips were put on a daughter card and then 8 daughter cards were plugged into a simple "backplane". If you imagine the 3D shape of a single "clock" copper wire running through this, you can see how it forms a nice antenna, and travels through quite a few physical connectors. And the wire shares this space with significant current being PWMed through the LEDs (these wires become RF transmitters). While today's chips "sip" so little current that fanout is not a problem, Tom's suggestion to buffer the clock is a good one because it would break the antenna and regenerate the degraded signal into a clean digital waveform. At the same time, processors are so cheap -- if you have to add any chip it opens the question of adding a uP and just generating the signal rather than a buffer and regenerating it.

  2. biggest crap IC ever...if you can find an on-the-go appliance, prefer it to this unstable overheating shit

  3. hello,

    i tried adding 1000 mifrofarads capacitor to protect the ic when i turn on my scope (an old crt) but i still fry my 5940

    can you help me about this ?

    how do i know the right value to put in the circuit ? how do i calculate that ?


    1. I'm assuming you mean when you are sampling the circuit with your scope, not just turning on your scope. If the latter, that implies your scope is putting some very bad waveforms onto your household power. But anyway both seem very unlikely unless your scope is somehow very broken. It would have to be introducing a > 3.3v transient into the circuit. Look at my edit (gotcha #0) -- that is much more likely to be your problem.

  4. To solve problem #0 would it not be a good idea to power the TLC5940 from the same supply as the LEDs - with a suitable voltage reduction when the LED supply is greater than 5v - and also to have the 5v go back to an input pin on the Arduino so that you don't send any signals back to the TLC5940 until you know there is power.

  5. Can you please suggest a "high-side driver chip" and how it would be used to prevent the LED vs Chip Power issue? It's not something I'm familiar with but I do intend to use this chip to control the brightness of a 12V LED tape strip so it's a real concern.