TLC69601-Q1: How to test the response of a UART interface?

Hi Neil,

Our expert is OoO and she will reply to you once he is back to office, thanks for your patience.

BR, Jared

Hi Jared,

Thank you for the update. I wanted to share the current status of the issue I’m facing. After reviewing the CSSI program example, I found that the F280039C should store the data in a buffer upon receiving a response and then execute subsequent actions. However, during actual execution, the buffer did not receive any data and remained in the waiting-for-response stage.

I modified part of the program to skip the waiting-for-response step and used another UART device to directly read the SOUT pin, discovering that I could receive response messages. For instance, when the brightness is set to 0x0123, reading the brightness of a certain LED returns 0x01 0x23.

I would like to first confirm whether the response from the TLC69601 in UART mode is indeed like this.

Next, I will continue to investigate the issues with the F280039C in the process of receiving data and storing it into the buffer.

Best regards,
Neil

Hi Nell,

Whole the team is on China National Day holiday till next TUE, pls expect some delays on the response. Thanks for your patience.

BR, Jared

Hi Neil,

Which version of code are you referring to?

Your understanding of this UART is basically right and I think you have read the data correctly based on your description. If you can read some registers and get the value you have written in, that will be better.

BR, Gracie 

Hi Gracie,

I found that the issue was due to the DIP switch configuration on the F280039C, which caused GPIO 28 to switch to XDS mode. After switching it back to BP, GPIO 28 can now receive responses as expected.

Next, I will test the register reading and error states. I would like to understand what methods TI typically uses when testing error states.

BR, Neil

Hi Neil,

I am not quite sure what methods you are referring to. If you are using UART/INT interface for readback, then when there is LOD/LSD, INT should be pulled low. and you can read FC27 to see the current status of last device. And you can also read the error register for the specific channel.

This is the diagnostic flow.

BR, Gracie

Hi Gracie,

Currently, I’m trying to read the FC26 register content from all 47 chips on an LED panel. When the LEDs are powered normally, the response is [0x00, 0x00]. However, after turning off the LED power, the response changes to [chip_idx, 0x10]. For the 47th chip, though, the response is consistently [0xFF, 0xFF], regardless of the power state.

What could be causing this issue?

Regarding the methods I mentioned earlier, they are similar to turning off the LED power to observe the changes in the LOD. However, I'm unsure how to conduct other tests. Could you recommend specific test cases or reference materials?

BR, Neil

Hi Neil,

Are you using TLC69601 for local dimming application? Are there 752 zones on your LED board? 

Could you pls contact us via mail for the project details? And I can see the result more detailly. For the LED board, I think if the brightness can be controlled correctly and LOD/LSD could be reported, it's already fine unless you have more complex system requirement.

BR, Gracie

Hi Gracie,

I’m currently using the TLC69601Q, and there are indeed 752 zones on the LED board.

Thank you for the information. This is something I want to try in order to observe their actual responses, and it is not related to any complex system requirements. If any needs arise later, I’ll reach out with further questions.

The remaining issue relates to the problems encountered when reading the FC26. Should we continue discussing this here or via email? If you prefer email, could you please provide your email address so I can follow up with the project details and share the results in more detail?

BR, Neil

Hi Neil,

I already sent you the friend request and want to send private message with my EMAIL address but you didnt accept.

BR, Gracie