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

Part Number: DS90UB947-Q1


Hi,FAE:

1.Fault description
The application using ds90ub947 and ds90ub948 may experience occasional black screen issues. After initializing ds90ub947 and ds90ub948 again and displaying normally for a while, black screens may appear again

2.LVDS video parameters
   clk freq = 85.18Mhz
   fps = 60Hz
   hfp:60,hs:22,hbp:10,hact:1920,htotal:2012
   vfp:3,vs:1,vbp:4,vact:720,vtotal:728
3. ds90ub947 register
   ub947 dtc failed, reg:0x5A,rdval:0x4d; fpdlink not ready
4. ds90ub948 register
   ub948 dtc failed, reg:0x1C,rdval:0x32; de-serializer not locked

Consultation questions:
1. What could be the possible reasons for incorrect register parameters in ds90ub947 and ds90ub948
2. I think it is related to the signal quality transmitted by the wiring harness. How to determine if the signal quality meets the design requirements of the chip
3. What are the signal requirements for FDPLINK transmission on twisted pair cables, what are the specific parameters, and how to perform detection

  • Hi Zhan,

    Thanks for reaching out. If the display is normal again and then eventually black screens, I would think you are accumulating errors on the link until the link drops. When this happens, are you still able to communicate to the DES at all (assuming your controller is connected to the SER)?

    What does your setup look like? Can you send a picture? And how many systems is this occurring on?

    I would investigate the cable. A simple thing to sanity check would be trying to swap the cable. 

    If you have local I2C access to the DES, you can run MAP analysis. Here is the information on how to set it up - 5633.MAP.pdf

    We have channel specifications as well, please reach out to a local FAE to assist with accessing this. 

    BR,

    Esther

  • Hi, Esther,

    Thinks.

    1. The entire processing flow is to wait for fpdlink connection after the video output is stable, initialize ub947 first, and then initialize ub948. After determining that the resolution of the video obtained by ub948 is normal, initialization is complete. Afterwards, the running detection module first reads the registers of ub947 once per second, and then reads the registers of ub948. Only after successful reading will the log be recorded. From the log, it can be seen that after the exception of register 0x5A in ub947, the value of register 0x1C in ub948 can be obtained.    
    That is to say, after reading the state "fdplink not read" from register 0x5A of ub947, the state "deserializer not locked" from register 0x1C of ub9478 can also be read

    2. There was one case in the actual vehicle

    3. Register configuration of ds90ub947

    Pdb hardware reset

    0x1E,   0x01

    0x03,   0xDA

    0x17,   0x9E

    0x4F,   0xC0

    0xC2,  0x80

    0x5B,  0x23

    0x16,  0x02

    0x04,  0x90

    0xC6, 0x21

    4. Register configuration of ds90ub948

    0x01,   0x02

    0x34,  0x09

    0x49,  0x60

    0x23,  0x20

    5. Is it necessary to conduct MAP analysis on vehicles with faults, and is it valuable to conduct this analysis on vehicles without problems?

    6. Is the high-frequency frequency transmitted on the twisted pair cable consistent between the single channel transmission mode and the dual channel transmission mode of fdplink with the same video parameter input?  I am currently using the dual channel mode, can changing to a single channel reduce the frequency of high-frequency signals on the twisted pair cable?

  • Hi Zhan,

    Thanks for sharing. Where did you get the register configuration script from? 

    Can you try the following: 
    Change LOCK definition by setting 948 Register 0x34[6] = 1. Can you then observe Register 0x1C and Register 0x5A? Do you have local I2C connection to the DES?

    For context, the default definition of LOCK is that there must be video being sent. Register 0x34 changes the definition to if the I2C communication across FPD-Link is successful (essentially, if the FPD-Link bidirectional control channel is still proper).  

    After changing the definition, if LOCK is still high during this black screen phenomenon, then it indicates an issue with the source not sending video. 

    If LOCK is not high during this black screen phenomenon, then it indicates an issue on the FPD-Link. 

    5. Is it necessary to conduct MAP analysis on vehicles with faults, and is it valuable to conduct this analysis on vehicles without problems?

    It would be helpful to compare the MAP analysis on vehicles with faults and vehicles without problems. This is occurring on 1 vehicle out of how many? And it's 100% reproducible on this unit? How long does it take until LOCK drops? 

    6. Is the high-frequency frequency transmitted on the twisted pair cable consistent between the single channel transmission mode and the dual channel transmission mode of fdplink with the same video parameter input?  I am currently using the dual channel mode, can changing to a single channel reduce the frequency of high-frequency signals on the twisted pair cable?

    By using dual channel mode, you are actually splitting the frequency between two channels, so switching it to single mode will actually cause the entire frequency to be concentrated on a single link. 

    BR,

    Esther

  • Hi Esther,

    1.

    I refer to the documents DS90Ux947-Q1 Init Code Example Rev 1p1.py and FPD-Link_S90Ux947-Errata. pdf, and configure them according to actual usage.

     RE: DS90UB947-Q1: source code or script when the link is unstable 

    I have analyzed the log information of the recently problematic vehicles and found that 4 of them reported FPD3_LINK_RDY=0. When ub947 malfunctions, 0x5C=0x4d; Normally 0x5C=0xcd. Only when this car reports this error, can it still read 0x1C=0x32 from ub948, indicating that De-Serialize not locked.

    2.

    Change LOCK definition by setting 948 Register 0x34[6] = 1. Can you then observe Register 0x1C and Register 0x5A? Do you have local I2C connection to the DES?

    anCurrently, no actual vehicle testing has been conducted. It is expected to conduct another test after the next malfunction occurs

    3.

    It would be helpful to compare the MAP analysis on vehicles with faults and vehicles without problems. This is occurring on 1 vehicle out of how many? And it's 100% reproducible on this unit? How long does it take until LOCK drops? 

    The map analysis has not been conducted yet, and it is not 100% reproducible. It randomly appears on the faulty car。Plan to conduct map analysis

    4. What is the direct cause of FPD3_LINk_RDY=0?

  • Hi Zhan,

    FPD3_LINK_RDY = 0 is most likely caused by the link instability. Link instability can most likely be attributed to signal integrity, and there are various avenues we can investigate. 

    Here are some preliminary checks:

    1) What is your power sequence? Please ensure the 947 is powered up first, followed by the 948. 

    Pdb hardware reset

    Do you PDB both the 947 and 948 before initializing?

    Here are some suggestions for when you have a system that has exhibited a failure:

    1) Read Register 0xA and 0xB on 947 multiple times. These registers give you the backchannel CRC errors. See if they are accumulating during runtime. Note down the values of these registers when there is a black screen. 

    2) Use MAP analysis on the system. This can be done any time, it doesn't have to be when the failure occurs. 

    When the black screen occurs, and LOCK is lost: 

    1) Attempt communication with the 948 remotely through the FPD-Link (eg - ReadI2C(desAlias, 0x0) should report back the desAddress) and see if it responds. 

    2) 

    Change LOCK definition by setting 948 Register 0x34[6] = 1. Can you then observe Register 0x1C and Register 0x5A? Do you have local I2C connection to the DES?

    You can try this as well. Thanks for your patience!

    BR,

    Esther

  • Hi Esther,

    1.  Enable the pdb of ub947 first, then enable the pdb of ub948

    2. I will use your suggestion to test on the faulty car, and I will send you the results

    3. I used map analysis in a normal system and found that everything is green. Is this normal?

    UB948 default map analysis configuration