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.

TVP5158 only one channel loss synchronization

Other Parts Discussed in Thread: TVP5158

Hi,

When I posted the following at E2E, I was introduced that the TVP5xxx forum is here.
https://e2e.ti.com/support/interface/f/138/p/795763/2944909#2944909

There is a problem that one of the four channels can not be synchronized.
Our customer use the TVP5185 to convert analog signal from camera into digital signal and output them to monitor.
They can see the flickering of the monitor image, and replacing the device will improve the phenomenon.
After that, they replace TVP5185 they are using when the problem occurs, the phenomenon reoccur.
So the customer suspects that there is a problem with the device.

【Question】
Have there been any events similar to the above in the past?
If yes, could you tell me why the phenomenon happened?

Best regards,
Yuto Sakai

  • Yuto Sakai,

    I can see from that post that you have already been notified about the support available for this part and how limited it is. I'm not sure that we will be able to provide this data as you've requested, but I will provide this to the right person to see if we can. Please note that they are out and the reply may be delayed until they return next week. I'm sorry for the delay.
  • Is the issue always with the same TVP channel? i.e. If you swap the video sources does the issue move with the source or stay with the same TVP channel?
    What do the video lock status registers indicate for each channel? Note, for the 'lost lock' status indicator you will need to clear the flag once video is present on each channel. This will then indicate that lock has been lost since previously cleared.
    How are you decoding the digital stream in order to display the resultant video? Are you 100% sure that this is not a host processing issue?
    Have you tried inverting the PCLK polarity? We have seen many issues where the clock polarity was not set correctly for the target processor resulting in setup/hold timing violations. What is your target processor?
    Most often these types of issues are setup/hold timing related either due to incorrect PCLK polarity and/or PCB routing.
    Are you able to look at the PCLK and each video databit with an oscilloscope as close as possible to your target processor? If so, please capture eye diagrams for each bit and make sure that you have sufficient setup/hold margin for your target processor.
    BR,
    Steve
  • Hi Steve-san,

    It occurs on the same TVP channel when replacing the video source.
    The video lock status register indicates 0.
    Also, the setup / hold margin is sufficient, and it is considered that this is not a processor problem.

    So why don't you investigate if the same phenomenon has happened in the past?
    If there is a case, could you tell me the cause and the countermeasure?

    Best regards,
    Yuto Sakai

  • Hi Steve-san,

    I'm sorry for bothering you.
    I have an additional question.
    What can we know by trying to invert the PCLK polarity ?

    Best regards,
    Yuto Sakai

  • Hi Steve-san,

    I'm sorry for pushing you.
    Could you give me your answer?

    Best regards,
    Yuto Sakai
  • Sorry for the delay but I have been out of the office for the past week. This is not an issue we have seen with any other customers, so will require some debug.

    If the video lock status indicates '0' then it is most likely an analog front end issue. Can you make some oscilloscope captures at the TVP5158 analog input pin with a time base of about 100us trace time and also with about 40ms trace time so that we can look at both the line period and frame period wave forms entering the chip?

    Can you also send me the schematics for the signal path from the connector to the TVP input, and if possible the layout database?

    The reason for trying the inverted PClk was to eliminate setup/hold timing violations as a potential cause, but if the lock status does not get set them this is most likely an analog issue.

    I assume that the lock status bits get set correctly for the other channels?

    BR,

    Steve