Post Go back to editing

TX.PLL_LOCK_STATUS suddenly becomes '0'

Thread Summary

The user experiences random video loss on one or both HDMI outputs (TXA, TXB) when using the ADV7625 in splitter mode, with PLL_LOCK_STATUS becoming '0'. The final answer suggests checking the HDMI source model and testing with the splitter disabled or using a different HDMI source to isolate the issue. A temporary firmware solution involves asserting TXA_RST or TXB_RST when PLL_LOCK_STATUS is '0'.
AI Generated Content
Category: Hardware
Product Number: ADV7625

ADV7625 used in splitter mode

Specific HDMI source → ADV7625 → HDMI monitor (TXA)
                                              └ → HDMI monitor (TXB)

In the above configuration,
if the image is left in normal display mode for a while,
the monitor image may suddenly disappear.

The disappearance is random: TXA only, TXB only, or both TXA and TXB.

When checking this state, the PLL_LOCK_STATUS for TXA or TXB is '0'.

Once this happens, the ADV7625 will not output video even if you connect an HDMI test signal generator.
(For example, if the loss is only on the TXA side, TXB will output normally.)

To recover, power cycle only the device equipped with the ADV7625

or

assert TXA_RST or TXB_RST in IO map 0xFE.

This issue is not a defect in any of the components listed above, including the ADV7625.
In other words, the same issue occurs even if you replace a specific HDMI source, ADV7625, and HDMI monitor with multiple different units.

As a temporary solution, we intend to add logic to the firmware (ROM) that asserts TXA_RST or TXB_RST when PLL_LOCK_STATUS = '0' to avoid the worst-case scenario of a "loss."

But essentially,
why did we end up in this situation?
I would like to find out, so please answer the following questions.

Q1: What can cause PLL_LOCK_STATUS to become '0'?
Q2: Please tell me how to recover from this other than asserting TXA_RST/TXB_RST.

Best regards,

  • Hi,

    Could you please share the status of the below items for our analysis?
    1.    The name/model of the HDMI source used for testing
    2.    Share the results using the same HDMI source with the splitter disabled
    3.    Test results using a different HDMI source with the splitter enabled
     
    Thanks,
    Ebin

  • hi,

    If I simply set SPLITTER_MODE_EN to '0' at RX1_PORT_SEL[2:0]=RX2_PORT_SEL[2:0], as you know, TXB will not output HDMI, what should I do?

    regards,

  • 1 and 3.    As already mentioned, there is no problem with sources other than Fujitsu FMVD60003.
    Note: D5 1080p60 without HDCP.

    regards,

  • Hi,

    We used the ADV7625 evaluation hardware for testing and applied a 1920 × 1080p @ 60 Hz input from the Astro generator. The splitter mode was enabled by setting bit 5 of register 0x02. With this configuration, we observed video output as shown in the image below.

    Image

    Could you please replace the monitor with a TVs and share the updated status?
    Please confirm whether you are using the ADV7625 evaluation hardware for your testing. If yes, kindly "route a txb" command(Baud Rate : 115200) using Tera Term terminal and let us know the results.

    In Addition,ADV7625 PLL locks depend on the incoming video CLK line So the CLK line must be stable, no jitter.  Make sure there is low noise on the power rails.  Reset adjusts the output square wave amplitude.  Lower values give greater amplitude.  Nominally the TMDS lines should be +-300mV with and offset of 3Vdc
     
    Thanks,
    Ebin

  • Hi, Ebin

    >With this configuration, we observed video output as shown in the image below.
    If (RX1_PORT_SEL[2:0]!=RX2_PORT_SEL[2:0]), then that's to be expected.
    When (RX1_PORT_SEL[2:0]==RX2_PORT_SEL[2:0]), TXB should disappear.

    >Could you please replace the monitor with a TVs and share the updated status?
    As I have already explained, the symptoms occur regardless of the monitor type.

    >So the CLK line must be stable, no jitter.
    I agree with what you say.
    However, even if jitter suddenly occurs and the image becomes distorted,
    I believe that the image should quickly return to normal once the jitter disappears.

    >Lower values give greater amplitude.
    Which register?

    >"route a txb"
    Below is the txb dump result when the issue occurred.
       x0 x1 x2 x3 x4 x5 x6 x7-x8 x9 xA xB xC xD xE xF
    0x 00 00 2D 80 00 28 E2 00-00 00 03 0E BC 18 01 13
    1x 25 37 20 19 1B 00 00 00-A8 00 00 00 00 00 00 00
    2x 00 00 08 00 00 00 00 00-00 00 00 00 08 00 00 00
    3x 00 00 00 00 00 00 00 00-00 00 00 80 00 10 40 00
    4x 88 10 60 7E 79 70 00 00-00 54 80 80 04 00 00 00
    5x 00 00 02 0D 00 00 48 00-00 00 00 00 00 00 00 00
    6x 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
    7x 01 0A 00 05 00 00 0B 00-00 00 00 00 00 00 00 00
    8x 7F 55 55 81 81 81 81 00-01 00 00 00 00 00 00 00
    9x 00 00 00 00 C0 00 FC 00-00 78 7C 00 82 30 00 00
    Ax 00 00 00 00 00 00 00 00-00 00 00 20 00 00 00 06
    Bx 00 00 00 00 00 00 00 00-20 00 70 00 00 00 00 00
    Cx 00 00 00 00 00 10 16 00-02 03 00 00 00 00 00 00
    Dx 44 3C 00 06 00 00 02 00-00 00 40 0B C0 48 18 14
    Ex 90 FC 02 D0 00 00 00 00-F0 20 1D FC 0C 40 40 41
    Fx 00 01 00 01 00 FF 08 F0-00 4B 05 DC 55 B0 00 5C
    In particular, 0xE4's 0x00 means "TX.PLL_LOCK_STATUS is '0'".

    Regards,