TFP401A: Signal Inaccurate - Causing monitor to display Distorted Image

Kacper

Can you share your schematic and layout for this design? 

Which resolution are you using right now? Is it possible to reduce the resolution and see if the distorted image goes away? 

Also, when you sent the video from the source, are you including audio as well? The TFP401A only supports video, it can't support audio.

Thanks

David

Hi David,

Thank you for your response. 

I have attached the schematic, but will send the layout when I am back in the office.

The TFT resolution is 1920 X 360 + blanking pixels. I have tried many different resolutions and only 1080p seems to work but is also distorted. 

I tried changing the clock frequency (this changed nothing), I suspect adding additional blanking pixels may have an effect, however I'm unsure what values to use as the EDID we are using was taken directly from a dedicated driver board for this specific TFT.

When audio was included in the signal, the TFT went into diagnostic mode, refusing to work properly. When all audio was removed from the EDID we started receiving the distorted image we are seeing now? Is there anything else that could be causing the issue in the EDID?

Thank you for your help, I really appreciate your help with the issue.

Best Regards

Kacper

8117.Schematic (1).pdf

Kacper

I am having question on the odd/even pixel connection between TFP401A and DS90C387, and am asking the FPDLink to double it check for me.

Thanks

David

Hello,

From even/odd perspective, this looks correct in schematic. However, it looks like the LSB/MSB might be flipped.  The below table/bit orientation will output VESA mode that this panel is targeting. 

Is TFP401 configured to flip LSB/MSB, or could that be the issue?

Kacper, can you try a solid red, green, or blue image to see if that displays properly? In this case, I don't think a a LSB/MSB would have impact on the image output.

Regards, 

Logan

Hi Logan,

I have tried the Pure blue, red and green outputs on a different thread, I supplied this at the beginning of this thread so please use this as reference for everything I've already tried.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1213055/ds90c387-signal-timing-inaccurate---causing-monitor-to-enter-diagnostics-mode#4579586

From these tests it seems that pure blue, red and green works correctly, but a colour that requires a combination of RGB doesn't respond properly. 

How certain are you that it's the MSB and LSB being swapped? - if this is definitely the case then we will try again with a redesigned board. However I want to be as certain as possible before wasting another 1-2 weeks on manufacture. 

I appreciate your help,

Best regards

Kacper

Hello, 

Since today is a US public holiday, we will continue support on your request on Monday. Thank you for your patience. 

Regards, 

Logan

Okay, thank you.

I have checked the connections also on the schematic and it agrees with both datasheets for the TFP401APZP and DS90C387VJDX/NOPB.

I carried out some additional testing with the solid RGB colours to try and understand what is happening:

I received the following results:

(0,0,0) RGB always resulted in a Black (No colour) display .

 - First it tested the RED idividual bit values (1, 2, 4, 8. 16. 32. 64. 128)

Red Bit Value 1 - I expected it to result in no colour change and remain Black, however there is a visible red colour.

Red Bit Value 2 - I expected it to result in no colour change and remain Black, however there is a visible red colour thats even brighter than Bit value 1.

Red Bit Value 4

Red Bit Value 8, 16, 32 all appear black and i have attached 32 as a reference

Red Bit Value 64

Red Bit Value 128

From the Above Results it seems to be that the bits are in the wrong order where bits 1 and 2 are actually the 2 MSB (this is also the case for Green and Blue bits). Can you please explain where the error could be, I have checked the datasheets multiple times and all connections of the data bits seem correct.

Thank you and Best Regards,

Kacper

Hello Logan and David,

Could any of you explain why im experiencing the behaviour above, and provide a solution please?

Best Regards,

Kacper

Kacper

Please see the pin definition and Table 9-1 which shows for example, RGB7 is on QD23 and QE23.

Is it possible to change the red pixel ordering on the PCB using blue wire and repeat the solid red color experiment?

Thanks

David

Hi David,

Thank you for your message.

Im pretty certain that the RGB outputs from the TFP401A are correct. Im convinced the error is caused by incorrect RGB connections to the DS90C387VJDX/NOPB.

I have tried to alter the Red connections using wire but the soldering/length matching inaccuracies caused me to get 'striping' on the screen and some channels were not being received correctly.

What i did instead is test each bit in the 8-bit Red value to see which is least and most significant in order.

What i found was the following (Even_Red Channel used as example):

R20(Pin 84) = R0 LSB

R21(Pin 81) = R1

R22(Pin 80) = R2

R23(Pin 79) = R3

R24(Pin 78) = R4

R25(Pin 77) = R5

R26(Pin 76) = R6

R27(Pin 75) = R7 MSB

This seemed to agree for all Even/Odd Green, Blue and Red Data although it was difficult to tell at low RGB values (<32) because the screen appeared almost black.

Can you confirm that these are the correct connections so that we can get a working PCB manufactured please.

I have attached the schematic with text explaining the changed connections for reference.

I also found a document that would agree with my new connections but i think disagrees with the DS90C387VJDX/NOPB datasheet?

https://www.hobbielektronika.hu/forum/getfile.php?id=164305

Thank you and Best Regards,

Kacper

Annotated Schematic.pdf

I dont belive these new connections can be correct based off of the very first set of tests carried out using the Red channel. What we proved was that R17 and R27 were the most significant bits. - This was tested by setting red value to 2, which set Red_B7 (odd & even) high. Setting R16 and R26 resulted in the halving of the Red intensity, it halved again when R15 and R25 are set etc...

I dont understand how you can tell me that B16 is the most significant bit when my tests show otherwise.

I also dont understand how you can justify the order of bits when, again, my tests show otherwise.

From my testing, the crossed out changed below seem to be correct, and I ask if you can please confirm this and not base your responses on the datasheet alone. I also ask you to do this because i have attached a seperate TI document previously which disagrees with the connections. I have copied it below again, please take a look.

www.hobbielektronika.hu/.../getfile.php

(Blue_B8 = LSB, Blue_B1 = MSB)

I look forward to hearing from you about whether you've been able to replicate this issue. We are planning to buy hundreds of these chips a year but it seems that we may have to look for a different solution with another manufacturer soon based on the lack of genuine support from TI.

Best Regards,

Kacper

Hi Logan,

Thank you for your response, we have since built a new PCB with the changed connections and have a working display.

There is one final issue that i cant seem to locate. It seems that interlaced pixels are offset by 1 somehow, im not sure how else to describe this.

I have tried multiple different combinations of settings pins on the hardware, and have also tried everything related to interlacing on the EDID.

Can you please suggest what could be causing this, either in the hardware or EDID?

I have attached images of the pixel offset below:

Could swapping the LVDS channels solve the issue? Swapping A0P - A3P to be the even data, and A4P - A7P to be the odd?

I look forward to hearing from you,

Regards,

Kacper