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.

TFP410 giving intermitting output

Other Parts Discussed in Thread: TFP410

Hi folks,

I use a TFP410 to convert 24bit RGB data (plus sync) to a DVI stream which is fed to a scaler and finally to a LCD panel.

It works quite ok, but on some boards I only get intermitting DVI signals. The CLK channel is running without pause, but the data channels send LVDS levels only for about 110ms and then pause for about 100ms. Of course no monitor or scaler works with such a stuttering timing.

Anybody any idea where that could result from?

Here the signals fed to the TFP410:
- 24 bit of RGB data, changing around the falling edge of the clock
- a 62MHz clock signal
- HSync, VSync and DE signals  as needed
- ISEL = low (=no I²C)
- PD = high
- BSEL = high (=24 bit data, single edge)
- DSEL = low (=single edged CLK)
- EDGE = high (= latch on rising edge of CLK)
- SCAN _EN = low (= normal operation)
- EXT_RES: 510R to AVCC
- DKEN = low (= DK1..3 unused)

All signals are fed from/to the chip via 22R serial terminated PCB traces and the output of the TFP410 goes to a HDMI connector where either a monitor's DVI input or a termination network is attached.

Greetings from Germany,
Stefan

  • Hi folks,

    attached you find a (slightly blurred) picture of the cumbersome timing on the LVDS/DVI lines (50ms/unit).

     

    The signal is ok where you see the hatches, but I have no idea why there are this 100ms gaps.

    Stefan

  • Exactly what signal is being captured above?  Can you compare the SYNC signals (Including DE) from the input of the TFP410 to the input of the LVDS controller(Output of the DVI receiver)?

  • Hi Undrea,

    as written above, the signal trace shows one line of the 4 LVDS pairs of the DVI interface (= the output of the TFP410).

    Meanwhile I know where the gaps are coming from: The DVI is connected to a scaler chip in the display. This seems not to recognize the video timing that our OMAP produces and its firmware then switches the termination off and looks for a signal at the analog input. After ~100ms it comes back, switches the termination on and scans for a valid (which means: known to its firmware) timing and so on.

    It looks that the next steps are to find out a) which timings are known to the scaler firmware and b) how to convince the OMAP's LINUX to produce them.