• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 159 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LMH0050: PLL doesn't lock and incorrect part identification from SMB

Zach Stokes
Prodigy 55 points
Part Number: LMH0050
Other Parts Discussed in Thread: LMH0040

I have an LMH0050 in my design serializing data from a Xilinx Zynq-7 into HD-SDI to output to a monitor.

The Zynq has GPIOs connected to the LMH0050's RSTn, LOCKn, SMB SCL/SDA, and all LVDS pairs.  It also controls the enable of the low-ripple power supplies for the IC.

At first I did not think I needed to configure over SMB at all for my purposes, but after trying every variant of toggling the enable, RSTn, and TXCLK (27 and 148.5MHz), the LMH did not respond at all, LOCKn stayed high and TXOUT did nothing. (I was also passing test pattern video to the TX data pairs)

Probing the registers over SMB I found that the LOS Status register returns 0x00 no matter what I do, indicating that the chip detects data and clock on the TX lines even when I know I'm not providing any.  The Event Status register also indicates that TXCLK has a clock on it, but agrees with the LOCKn output that the PLL can never lock.  Finally, the chip identification register returns that I have an LMH0040 in system, but the package is labelled LMH0050.

I'm at a loss, probing close to the IC shows that I am giving it the inputs I believe it wants.  Any thoughts on what to try next?

  • 0
    TI__Guru* 88835 points

    Hi Zach,

    I've been thinking about this. I would've thought as long as you have the right clock rate with +/-500ppm we should be able to lock. I am assuming this is the case. The only thing that comes to mind is perhaps a reserved pin, DNC, DVB_ASI, loop filter cap connection, or some other pin around the device is not biased properly. Sorry these are what come to mind and i am not able to directly pin point the issue here.

    Regards,Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 55 points

    An update on this.  I've continued to check things out and the PLL does lock if I disable FIFO errors in register 0x27, though I am still not getting any movement on the output.

  • 0 in reply to Zach Stokes
    TI__Guru* 88835 points

    Hi Zack,

    Please confirm you are using a transmit clock within 500ppm. 

    Also, you are using regular color bar pattern?

    Also, are you using example FPGA code to initialize the part? It would be good if you could please let us know the overall block diagram.

    Regards,Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 55 points

    I am using a transmit clock within 50ppm.

    I am only using your example RTL to provide data and clock to the IC.

    I have tried several test patterns, each generated from my own IP.

    The SMB bus is controlled by a standard Xilinx IIC IP.

    I probed LOCKn with a logic analyzer and found that the PLL can lock for a few thousand cycles, but then loses lock randomly.  I could not discern any pattern in where it acquires or loses lock relative to the incoming video data.

  • 0 in reply to Zach Stokes
    TI__Guru* 88835 points

    Hi Zack,

    Example Xilinx IP i thought does color bar pattern generation as well - after initialization of the device. You may want to let the example IP do initialization and the pattern generation- just to see if we can maintain lock.

    There are two reasons that i can think of for not maintaining CDR lock: Either there is too much jitter on the incoming data or on the reference clock. It could be a good idea to put the reference clock or LVDS data on a infinite persistence scope to see if there could be high jitter causing device to lose lock.

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 55 points

    Nasser,

    Thanks for the troubleshooting but it appears to have been an electrical problem after all.

    I accidentally fried the IC while trying to probe and we replaced it.  Now it is working fine.  Best guess is that one or more of the pins had bridged to the ground pad underneath and with the replaced IC that is no longer true.

    In any case, all is now well with the LMH0050, and I am on to the next part downstream.

    - Zach