This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sync issues with TFP401A when input signal changes

Other Parts Discussed in Thread: SN75LVDS83B, TFP401A, TFP401

Hi

I have a TFP401A that interfaces to a SN75LVDS83B to drive an TFT with LVDS input. Signal source is HDMI/DVI from a STB SoC.
After boot, the SoC first outputs its default 1080p until I have it initialized to 1280x800 for the TFT.  During the 1080p the TFP401A shows SCDT, quickly loosing it while switching the resolution and showing it again for the 1280x800.
However, the output signals are not ok until I remove the supply from the TFP. Reseting it does not correctly catching up the new input rate. After removing and reapplying the supply it correctly syncs and everything is fine. This happens after every change of the input signal.

Is this normal behavior of the TFP401?

Thanks for your help.

  • Franz, have you tried toggling pin PD# after changing to 1280x800?

    Thanks,
    RE

  • Yes, to no avail.

    When I use a HDMI/DVI splitter and connect another display in parallel, the other display always syncs perfectly. It's the TFP401A that somehow does not sync to the source and still it sets SCDT. If I look at the output signals, I can see that there are spurious pulses on the DE when it should be low after VS before active content starts. See the attached pdf.4657.Sync Issues.pdf

    I also found that during the issue, I have the same spurious pulses on CTL2 and on DE (mixed with DE) whereas CTL2 is low if it's OK.

  • Hello Franz,

    That spurious signal on DE is really bad, somehow your DVI transmitter is encoding noise when transitioning to a different resolution,  are you connecting SCDT to /PD ?

    The TFP401 is not detecting HSYNC and VSYNC because it is always seeing DE transitioning, if you reset your DVI transmitter instead of the TFP I suppose the issue goes away, am I right?

  • Further analysis showed that the spurious DE is always on the TMDS input, even if the TFP decodes and somehow suppresses these DE, that is when the output is perfect. I have SCDT and /PD connected. SCDT shows detected in both conditions, bad and ok. Using /PD does not help. Neither does deconnecting DVI and reconnecting. The only way out is to remove and after about 5sec reapply supply to the TFP. A TV connected in parallel for testing purpose is able to correctly decode and display.

    However, it looks as if I have to look for the spurious signals on the TMDS input first. I'll get back to this thread after some deeper analysis of the DVI source.

    Thanks a lot so far.

    Franz

    2185.Sync Issues 2.pdf

  • I have to revise my post from this morning.

    I tried with a different HDMI source (PC) and found the same situation. The TV always shows everything  whereas the TFP401A only decodes correct video signals after a power-sequence with the TMDS already attached an running.

    To me, this looks like a bug of this chip ... or did I miss something ... maybe some configuration?
    Does the chip have problems with the other signals that are part of the HDMI next to the video?

    We are under very high time pressure with this thing and I need to get this nailed as soon as possible.
    Thanks a lot for your swift support in advance.

  • Franz, out of curiosity, what if you have the TFP401A disconnected, then power up your system where the SoC first outputs 1080p and then switches to 1280x800, and then connect up the TFP401A?  Does the problem still occur and you have to power cycle, or does it work right away?

    Thanks,
    RE

  • Here's what I did:

    - All powered down, HDMI disconnected
    - Power-up SoC, starting with 1080i
    - Changing output to 1280x800-60 and starting Video content (TV shows image in 1280x800-60)
    - Powering up TFP401A
    - Connecting HDMI to TFP401A
    - There we have the bug!

    Power-cycling the TFP401A makes it work.
    Disconnecting in working state and reconnecting turns into buggy state.

    To circle the issue I changed the Software that drives the HDMI on the SoC to output in DVI mode only and don't send Audio and what not to the HDMI connector.
    Et voila: The TFP401A detects very quickly and always perfectly!

    My conclusion: The TFP401A - though advertised as (SLLA325 –February 2012) - is not really usable with HDMI signals and is limited to DVI signals. It gets disturbed by all the other contnet on the HDMI and is not able to reliably sync to and output RGB video.

    Franz

  • Hi Franz,

    There appears to be two issues here.  One is, your TFP401A isn't functioning unless you cycle power during video transmission to it.  I'm not sure why this is happening, and I haven't seen this behavior before.

    The second issue is of course the HDMI audio.  You're correct that the device can't handle audio packet information, as it messes up the expected TMDS data during blanking.  I maybe should have pointed this out in the app note.  I might revise it to add this comment, to prevent others from encountering this.

    Are you able to disable audio from your HDMI output?

    Best regards,
    RE

  • Hi Ross,

    Yes, I can disable all other output on the HDMI, i.e. configuring it as DVI because I actually need the video signal only in this design. This is exactly what I am going to do.

    However, it would have helped a lot and would have saved me quite some time if this was pointed out in the data sheet, the web or at least in the app note. IMHO, if talking about HDMI it definitely means all of the signals that may be expected, otherwise it simply is DVI (for video, for instance) and nothing else.

    Thanks for confirming and best regards,
    Franz

  • Yes I agree with you.

    So when you configure as "DVI", all problems including the power cycling fix go away?

    Thanks,
    RE

  • Yup. With DVI input signal I can /PD, Power-cycle, changing resolutions on the fly, disconnect and reconnect while running - all the stuff that did not work before - and it always syncs perfectly .... so far ;-)
    That's what I call stable operation now.

    Regards,
    Franz