TLC59116: LED Operation Failure with Multiple Modules and Drivers

Part Number: TLC59116
Other Parts Discussed in Thread: TPS22918

Hello everybody, this is my first post on this board as we are trying to integrate a Texas Instruments LED Driver into our design and have come across an issue that we haven´t been able to solve. We are in a hurry to get the design finalised and would greatly appreciate any assistance given.

We have 12 LEDs modules, each of them consists of 2 PCBs (just now for testing purposes), one for the driver and one for the LEDs.
Both PCBs are one sided aluminium boards.

For the driver board we follow the typical design, which consists in just the driver IC, a 0.1uF capacitor between VDD and GND, a 187ohm resistor for fixing the current flow on the LEDs close to 100mA and a micro switch for I2C addressing (by using it we can control 12 modules on the same I2C bus).

The LEDs board simply hosts the 11 required LEDs (8 white, 1 deep red, 1 royal blue and finally 1 far red).
* All white LEDs are exactly the same model (LM301H from samsung MPN:SPMWHD32AMH5XAV5SK) which can draw more than 100mA, so we use one driver channel per LED.
* The deep red one (LH351 from samsung MPN:SPHRD1L3DH00A4R2D2) is able to draw more than 300mA, so we´re using 3 channels from the driver board.
* Far red (L1SP-FRD00035R0000 from lumileds) and royal blue (L1SP-RYL0003500000) are expected 180mA and 200mA, so 2 channels per LED this time.
By now, on our first tests, for all colour LEDs are only using one channel, so 100mA maximum per LED.

LED Module: 11 x LEDs with total max demand per module 1500mA (or 1100mA with all on 1 channel).

Power Supply: Mean Well RPS-75-5 rated at 5VDC 14A (link)
Supply should be enough for at least 8 modules fully on (8*1500mA=12A).

Micro Controller: ESP32 (Dev Kit V1)

Problem: when powered on several LED modules everything seems to be ok for a few seconds, and then some of the modules go off completely, but not all the modules.

The problem occurs when using more than 3 modules. It seems to be that the driver resets. We think that because we can do a software reset and send the I2C command again to turn the module on as normal but when some time passes it fails again.

Test 1: The ESP32 and the drivers board were powered by using the mentioned PSU (everything powered at 5VDC).

Test 2: Connect he ESP32 and the driver board to another Power Supply (with common GND) and letting the full Mean Well Power Supply just for the LED Modules, but the same result.

I'm wondering if the fault could come from the power supply. Think that what the drivers really do is to quickly open and close the current flow through the LEDs, I'm working on pwm mode for controlling the brightness, so perhaps it's causing some weird behaviour on the power supply, of perhaps it's affecting to the VDD at the driver input, or even to the reset pin (which is connected to the VDD line).

Later we found an Evaluation Module (link) for the drivers and I see that they are using a 1.0uF between VDD and GND at driver IC side (remember that I'm using a 0.1uF)
Another important thing is that you are using a multilayer design for the PCB and mine is one sided (aluminium).
I can't see more great differences between my design and the Evaluation Module.

I also checked the I2C line from the ESP32 (I'm using pullup resistors, 2*4k7 in parallel for SDA and SCL) thinking that perhaps it could be a bus issue but I don't think that because when resetting the bus everything comes normal.
Anyway I also tried to use an Adafruit I2C extender (link) in order to increase the quality on the I2C comms, and the result was the same as described above.

Could it be an EMI or noise issue?

Some additional notes:

It is not always the same module that is resetting.

The output current is fine on all driver channels until the LEDs turn off, at which point the current goes to 0.

The LEDs are being held at steady state when the problem occurs (using PWM to control intensity).

Thank you


  • Hi Peter,

    Could you help to share your schematic and the register setting with us?

    How about the power up sequence for all modules, all at the same time or one by one? What I suspect is the same as your worry about the power supply, that if it have the capability to drive such high current at the same time without VDD falling. I think you could capture the waveform of VDD/RESET/ILED to see if VDD dropped below VPOR.

  • Dear Hardy,

    Please find the below summary from our electronics engineer in answer to your questions.

    Please, find attached schematics (driver_module_sch and led_module_sch) and also the code for the registers setup at initialization at the end of the post. 

    Now, I'll try to explain my tests.

    First of all, you must know that I'm using a 5VDC PSU for powering all the LEDs modules and the drivers. The I2C bus is operated by using an ESP32. All the GNDs are connected together (PSU, drivers and ESP32). Regarding the I2C bus, I'm connecting the SDA, SCL and GND signals from the ESP32 to the drivers, but using a different power supply.

    I'm driving the I2C at full speed (400 kbps). At the first tests I thought that the issue could be related with bus length, or speed, so I tried to decrease the pullup resistors and also decreased the speed, down to 10kbps, but no success.Then I tried with a Low Voltage I2C/SMBus Accelerator (LTC4311 from Linear Technology Corporation), but the issue still persisted.

    Once discarded bus problems, I have been doing lots of tests and inspecting the signals by using an oscilloscope and also a digital analyzer.

    In the attachments you can see some pictures captured from the oscilloscope and also from the digital analyzer.

    In the first picture (1-VDD_capture) you can see the capture from the oscilloscope for PSU output (yellow) and the driver VDD line (blue) when just one LEDs module is doing pwm at 100% (you know, almost fully on, but still in pwm mode). As you can see in the capture some spikes arise at a frequency close to 100khz, it seems to me like the spikes have to do with the pwm switching. You must also know that the driver's Reset signal is directly connected to the VDD pin, so the same signal is shared for them.

    In the second picture (2-PeekToPeek) you can see the peek to peek capture from the oscilloscope and here it seems to be clear that there are spikes which goes as low as zero at VDD (blue line), so I'm suspecting that when the voltage drop is wide enough the driver enters on reset status and loses the configuration so it's needed to do a software reset in order to gain control again, and it matches with the experiences I have got in my tests.

    In the third and fourth picture (3-Setup_1 and 4-Setup_2) you can see the complete setup and wiring for the modules (only 6 from 12 total are connected).

    Finally, in the fifth picture (5-PSU) you can see the PSU (also you can see a DC-DC converter I included in latest tests trying to stabilize the power for the drivers, which previously was connected directly to the PSU).

    As far as I could see, the problem arises when powering more than 3 modules at the time. If I only power 3 modules everything seems to be ok, no noise can be seen affecting the I2C bus, neither the reset signals. But when powering up more than 3 modules the noise increases very much, in such a way that it is absolutely easy to see it affecting mainly the reset signals and even the I2C bus lines.

    So, my guess is that some reset lines drop below the threshold for a time enough to put the driver into a reset state and reboots it.

    The capture from the digital analyzer responds to an specific programmed sequence, which first do a soft reset to all modules, and then initializes them (see the code for reset and initialization at the end of this post), then it waits for 1 second and power on (100% pwm) the first module, wait for 1 more second and then power on the next one, and so on until get 6 modules fully on, then finally it waits for 4 seconds and then power all modules off.

    In the global capture (analyzer-global) you can see I2C lines and 6 reset signals.

    You can find attached captures for initial soft reset and initialization (Analyzer-ResetAndInitialization) and the I2C commands for the module 1 (Analyzer-Module1) and 2 (Analyzer-Module2), all following commands are almost the same, the only difference is the module address.

    As you can see everything goes right until I power several modules (Analyzer-Noises), based on my experience it used to be when powering more than 3 modules, then appears noise on some reset signals and even in SDA and SCL lines. So I'm suspecting that perhaps sometimes if a reset signal drop is wider enough it's seen by the driver as a real reset order and then reboots.

    As mentioned above, we are using a 5VDC 75W PSU from Meanwell rated up to 14 amps, so it could be enough to drive up to  8 or 9 modules. I think that the issue could be related with the inability of the PSU to instantly provide the high required current pulses (given that the driver is doing pwm with the current coming from the PSU).

    Please, do you have any suggestions for solving this issue?

    Can you have a look into the PSU specifications in order to see if it's not good for our needs?

    If you think that the problem is finally in the PSU, could you recommend a good power supply?


    At program starts the sequence is:

    - first, perform a softreset to all devices as follows:

    void softreset() {





    - then, init all the modules (by using the AllCallAddress) and configuring as follows:

    void init_module(int addr) {

      Wire.beginTransmission(TLC59116_BASEADDR | (addr & 0x0F));

      Wire.write(0b10000000); // 

      Wire.write(0b10000001); // MODE1

      Wire.write(0b10000000); // MODE2

      for (int i=0; i<16;i++) Wire.write(0); //  PWM Individual duty cycle for channel

      Wire.write(0x00); // GRPPWM

      Wire.write(0x00); // GRPFREQ

      Wire.write(0b10101010); // LEDOUT0

      Wire.write(0b10101010); // LEDOUT1

      Wire.write(0b10101010); // LEDOUT2

      Wire.write(0b10101010); // LEDOUT3

      Wire.write(0b11010010); // SUBADR1 (D2)

      Wire.write(0b11010100); // SUBADR2 (D4)

      Wire.write(0b11011000); // SUBADR3 (D8)

      Wire.write(0b11010000); // ALLCALLADR (D0)



    210222 Answer to TI

    Thank you

    Kind Regards,

    Peter Overell

  • Hi Peter,

    Thanks for your detailed description. 

    From you waveform that LED operation does cause large ripple on supply. I think it is better to separate power supply of LEDs with LED drivers to avoid unpredictable reset.

    I saw that you mentioned that there is another power supply for ESP32. What is the voltage rating for this supply? Is it OK to connect RESET pin directly to this supply or a GPIO of ESP32, even VCC of LED drivers?

    As for PSU suggestion, sorry that I am not expert for power supply. You may need to consult PSU manufacturer for analyze.

  • Dear Hardy,

    Thank you for your response.

    We have done tests on using a different power supply for the drivers and reset pin with the same result. We believe the issue persists due to having a common ground between the LEDs and the driver.

    We have purchased another power supply to see if it improves the situation (we are still waiting for delivery), other lower current power supplies we have seem to work fine but they do not drive the LEDs at full current, so we still need to test the new supply.

    We have also seen a design from TI that includes the TPS22918 on the driver power supply. We assume this is to limit the inrush current affecting the driver Vcc and RESET pins and so have purchased an evaluation board from yourselves which should arrive next week.

    Ideally we need the final design to operate from 1 power supply and so if this is a power supply issue, we need an adequate power supply and/or an extra component such as the TPS22918 to ensure consistent performance.

    Please let me know if you have any comments on our proposed tests or any other suggestions, thank you.

    Kind Regards,

    Peter Overell

  • Hi Peter,

    Thanks for sharing the test process and results. I have no other concerns.

  • Dear Hardy,

    We have continued working on our tests and we’d like to share with you some insights.

    We changed the PSU we were using, now we are using a much more powerful one. This time we are using a 5VDC 40A PSU. So, in theory the PSU is able to deliver much more current than we really need.

    At first sight the result was the same, some modules became off during normal operation, that is, we put all of them at 100% PWM and some time later (seconds) some of them reset (and these off LEDs need to be restarted to work again).

    We have noticed significantly better results when setting the power supply to near 4VDC instead of 5VDC, but the problem doesn’t fully disappear.

    We have also noticed an improvement if we use separate power supplies for each set of 6 modules, but the problem persists.

    In all our previous attempts we were controlling each entire module together, that is, we moved all 16 channels at a time. That way we are switching up to 1.6A per module when doing pwm, and we do that at I2C full speed (400000bps).

    The more exigent test is when doing a continuous cycle of increasing the pwm value from 0 to 255 and then decreasing from 255 to 0, doing something like a heartbeat, at full speed. Running this test some modules reset very very quickly.

    We have now done a new test, this time we changed the settings at code level in such a way that we only switched 4 channels at once, again at I2C bus full speed, we run the heartbeat cycle but only for 4 channels, and then we run again for the next 4, and so on until we pass over the 16 channels. Please, note that at each time we only have 4 channels lightning per module (so, pwm is working for 400mA)

    Surprisingly we have seen that everything runs perfect in this last setup, all modules lighting smoothly, no module reset (we run the test continuously for hours…).

    So, could our issue be related with the PSU inability to provide such a current peak with all 16 channels, or is the driver which is not able to manage such a current switching?

    Please, could you have a deeper look at our design to help us to solve this issue?

    Do you think it would help by using some capacitors on the incoming voltage at the LEDs module? If so, could you help us calculate size and type required?

    Do you have an example circuit of using 12 drivers at full capacity similar to our requirements?

    We need to be able to power the 12 drivers and LEDs from 1 power supply and have confidence that it will perform over the lifetime of the product of 10 years, so we need to determine what characteristic of the design is causing this problem. Could it be noise from the PWM voltage control of 1600mA going through the driver or is it the inrush current requirement of the drivers operating 12 drivers at 1600mA each with PWM. If it is the inrush current, why is this affecting the LED driver on a different power supply? Should we use an additional circuit to smooth the PWM controlled current changes and thus reduce the inrush current requirement?

    One last thing, we noticed some flickering on the LEDs when doing pwm at some specific levels and keeping it fixed, for example at 20%. The flicker is easily visible. Do you know why we would be seeing this unwanted effect?

    Thank you in advance.

    Peter Overell

  • Hi Peter,

    Sorry for late reply that I am out of office these days. Unfortunately we do not have example circuit of using 12 drivers in full current capability and I also do not see such design before.

    One thing occurs to me that I saw you are using TSSOP package version in your design. It have worse thermal performance comparing with QFN package. Your test that using 4V have better results than 5V remind me that the reset behavior may caused by overtemperature protection. A quick evaluation for thermal that assuming all output pins dropped 2V and setting at 100mA, the increased temperature would be around 2*0.1*16*78 = 249C which is much higher than the threshold. (78W/C is RJA in datasheet section 7.4) Do you have any thermal equipment like IR camera to evaluate measure the temperature over IC? 

    Using QFN package and setting VCC to 4V seems OK theoretically, whose increased temperature is around 1*0.1*16*34.3 = 54.88C