• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 197 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DS90UB947-Q1: ds90ub947 fdplink not ready, ds90ub948 de-serizlizer not locked

DS90UB947-Q1: ds90ub947 FPD3_LINK_RDY = 0

zhan jin
Prodigy 70 points

Part Number: DS90UB947-Q1
Other Parts Discussed in Thread: ALP

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1584643/ds90ub947-q1-ds90ub947-fdplink-not-ready-ds90ub948-de-serizlizer-not-locked/6112860

Hi FAE,

According to the suggestions of ESther Chang, I carried out the map analysis under the normal operation of the real vehicle. The RX0 and RX1 measurement results are all green. There is no FDP3_LINK_RDY=0 in the actual vehicle tracking, and the map analysis was not carried out when the fault occurred. The fault should be an occasional problem. I want to know what factors are related to FDP3_LINK_RDY=0, and then we can carry out targeted design checks. I use ALP to detect that the pixel clock of the ub947 has a slight jitter. Is FDP3_LINK-RDY consistent with it is LVDS clock signal related?

 

 

 

  • 0
    TI__Expert 5193 points

    Hi Zhan,

    Thank you for providing the previous E2E and the MAP tool results.

    Can you confirm that this MAP program was run on a vehicle that showed the failure at occasional times? May not be run at the same time as failure but we want to ensure it is the same setup.

    zhan jin said:
    Is FDP3_LINK-RDY consistent with it is LVDS clock signal related?

    The FPD3_LNK-RDY signal does depend on the incoming LVDS clock signal. The FPD3_LNK-RDY bit is determined by FPD3 PLL and OLDI PLL locking to the correct frequency and detecting a valid device downstream via BC I2C communication.

    If we set 0x5B[5]=1 RST_PLL_FREQ, the FPD3_LINK_RDY flag should only depend on the FPD3 PLL lock and downstream deserializer detection (no OLDI PLL dependency)

    From the prior E2E, can you share a register dump of the 947 and 948 at the time of failure? 

    We are looking for BC_CRC errors on the 947 and FC_CRC errors on 948. This will give us direction on whether this is a signal integrity issue on the FPD3 datapath.

    Thanks,

    Ragav Subramanian

  • 0 in reply to Ragav Subramanian
    Prodigy 70 points

    Hi Ragav Subramanian，

       When the real vehicle fails, it recovers. The follow-up tracking does not reproduce the fault, and all registers of 947 and 948 are not recorded。

       When FPD3_LINK_RDY=0, is it possible that video transmission is normal?

       When FORCE_LINK_RDY =1 is configured, whether the back channel is no detected？FPD3_LINK_RDY=0  indicates that the forward channel is abnormal

       Thanks

        

  • 0 in reply to zhan jin
    TI__Expert 5193 points

    Hi Zhan,

    zhan jin said:
    When FPD3_LINK_RDY=0, is it possible that video transmission is normal?

    I would not expect video transmission to be normal when FPD3_LINK_RDY=0 as the state machine will wait on FPD3_LINK_RDY before driving forward-channel video.

    zhan jin said:
    When FORCE_LINK_RDY =1 is configured, whether the back channel is no detected？FPD3_LINK_RDY=0  indicates that the forward channel is abnormal

    FPD3_LNK_RDY=0 indicates the back-channel may have issues. If the back-channel is not operating correctly and no deserializer is detected, FPD3_LINK_RDY goes Low and the device will wait for FPD3_LNK_RDY to go high before transmitting video.

    Can you please perform test below:

    • Enable back-channel CRC generator on deserializer
      • Set 0x03[6]=1 Enable CRC generator
    • Measure back-channel CRC errors on serializer locally
      • Set 0x03[7]=1 Enable CRC checker
      • Read 0x0A or 0x0B CRC errors

    Thanks,

    Ragav Subramanian