TLC5941-Q1: About Vcc

Hi Kaji,

If the unwanted LED display happens just after the device is re-powered, it seems that the device is not fully reset. We should avoid this kind of phenomenon.

Please let me know when the communication occurs. Is there communication while the VCC is falling or rising? And if some LEDs may not display after the VCC is re-powered, will the host send all the commands again?

Best regards,

Suchen

Thank you for your reply.
I will check with my customer regarding the timing of communication.
Also, if the device does not reset, please let me know if there are any requirements for Vcc.
The data sheet does not mention anything about Vcc UVLO, etc.
Best regards,

Hi Kaji,

TLC5941 does not have such features like UVLO. Hence, we should guarantee a clean power up or re-power up to avoid any unexpected behavior.

Best regards,

Suchen

Thank you for your reply.
My customer is continuing to investigate this issue and has updated me on the status.
First, this system has an LED driver and a CPU that sends data to it.
Both are powered by the same 3.3V.
The situation is that while the LED driver is communicating with the CPU, the 3.3V drops and the CPU resets.
After that, when the 3.3V returns to a normal voltage and communication resumes, the LED may not display correctly.
(Question)
Based on further consideration by my customer, I will revise my original question.
If communication with the LED driver is interrupted midway, is it possible that the display will not function properly even if communication is resumed?
If this happens, will the LED driver not return to normal unless its power supply is turned off (=0V) for a certain period of time?
Best regards,

Hi Kaji,

Theoretically, even with incomplete re-power, if the CPU sends a complete command to the LED driver after communication is restored, the LED driver will work normally.

Best regards,

Thank you for your reply.
Is there any reason why the LED is not working properly?
Please let me know if there is any other information you need.
I will check with my customer.
Best regards,

Has the customer has checked the communication detail? The first thing is to guarantee the data is wrote the driver correctly after the communication is recovered.

Best regards,  

Thank you for your reply.
I got additional information from my customer.
It seems that when XLAT is H during communication, the CPU is reset, the port goes into Hi-Z, and XLAT slowly drops, causing a malfunction.
If the device is subsequently restarted with Vcc=0V for less than 100ms, it will operate abnormally.
We would appreciate any comments regarding the above behavior.
In the attached diagram, red indicates XLAT, light blue indicates SCLK, and yellow indicates Vcc.
Best regards,

Hi Kaji,

It's a very special scenario when the chips are re-powered with short intervals.

1. Give a discharge path for XLAT.  Please add a pull down resistor at XLAT to see any improvement.

2. If the chip works abnormally, please also check the XERR status.

3. Has the customer checked with the data bits detail? All the DC data and greyscale data are corrently written into the LED driver?

Best regards,

Suchen

Thank you for your reply.
I also really appreciate the information you provided about what to check.
I will confirm with my custmer the three points you mentioned.
Just to confirm, based on the information we have at present, is it possible to say that XLAT's behavior is causing the abnormal operation?
Since this is a special situation, are there any other factors that could be contributing to it?
Best regards,

Thank you for your reply.
My customer added a pull-down resistor to the XLAT and confirmed that no abnormal operation occurred.
Therefore, this thread will be closed.
We appreciate your response.
Best regads,