TLC59116: LED Operation Failure with Multiple Modules and Drivers

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?

REGISTERS SETUP:

At program starts the sequence is:

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

void softreset() {

  Wire.beginTransmission(0x6B);

  Wire.write(0xA5);

  Wire.write(0x5A);

  Wire.endTransmission();

} 

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

  Wire.endTransmission();

 }

210222 Answer to TI Attachments.zip

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.

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