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.

DS90UB960-Q1: about the DS90UB960's MIPI signal

Part Number: DS90UB960-Q1

Dear,

I used the DS90UB960 like below block diagram.

And, It works, also it's the mipi signal in this state. ( Picture1 )

[Picture1]

But, When I do the ESD test ( Electro Static Discharge ), this MIPI signal was broken like below picture2.

[Picture2]

Aslo, the picture3 is an enlargement of picture2 

[Picture3]

I think that this MIPI signal was broken by ESD (Electro Static Discharge)

Please, advice for this ESD test ?

best regards,

hosung shin.

  • It's our schematic for DS90UB960.

    best regards,

    hosung shin.

  • Hi Hosung,

    Thanks for reaching out with this question. Could you please provide more details on the ESD testing completed which resulted in this MIPI disruption? The below information would be helpful:

    • Test conditions of ESD
      • contact or air discharge?
      • what voltage level?
      • contact point? if on EVM?
    • Have we read back any diagnostic register to confirm if this is due to CSI-2 TX or link drop?
      • 0x4D & 0x4E read back during testing would be helpful

    Appreciate your help with more background on this issue.

    Best,

    Thomas

  • Hi Thomas,

    Our test conditions of ESD is..

    [1] Test conditions of ESD

         contact or air discharge >>  contact

         what voltage level >> 8k voltage ( 8000 Volt )

         contact point >> all of case.

    [2]  Have we read back andy diagnostic register ...

       >> When the mipi signal was broken, it's very short time like below picture

           the RED box is broken signal.

           then, I can't read this register on this time.

    best regards,

    hosung shin.

  • Hi Hosung,

    Can we read registers after this failure occurs? There are some bits such as the lock lost flag in register 0x4D that hold until read so we can see evidence that there was a lock drop.

    Best,

    Thomas

  • Hi Thomas,

    Sorry, too late.

    It's the dump values before ESD

    root@imx8mp-lpddr4-evk:~# i2cdump -f 1 0x3d
    No size specified (using byte-data access)
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-1, address 0x3d, mode byte
    Continue? [Y/n]
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 7a 00 1e 40 d0 01 00 fe 1c 10 7a 7a 0f b9 00 ff    z.?@??.???zz??..
    10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 02    ..............??
    20: f0 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ??..............
    30: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00    ..?.............
    40: 00 a9 71 01 00 00 20 00 00 00 00 12 00 00 02 00    .?q?.. ....?..?.
    50: 00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00    ........?.......
    60: 00 00 00 00 00 00 00 00 00 00 00 00 00 7f 88 88    .............???
    70: 2b 2c e4 00 00 00 00 c5 00 01 00 00 20 00 00 00    +,?....?.?.. ...
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    a0: 00 00 00 00 00 1b 00 00 00 00 00 00 00 00 00 00    .....?..........
    b0: 1c 3a 14 08 25 00 18 00 ff 33 83 74 80 00 00 00    ?:??%.?..3?t?...
    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    d0: 00 43 94 07 60 f2 00 03 00 00 00 00 00 00 00 00    .C??`?.?........
    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    f0: 5f 55 42 39 36 30 00 00 00 00 00 00 00 00 00 00    _UB960..........
    root@imx8mp-lpddr4-evk:~#

    And, it's the dump values after ESD

    0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
    00: 7a 00 1e 40 d0 01 00 fe 1c 10 7a 7a 0f b9 00 ff z.?@??.???zz??..
    10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 02 ..............??
    20: f0 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??..............
    30: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ..?.............
    40: 00 a9 71 01 00 00 20 00 00 00 00 12 00 00 02 00 .?q?.. ....?..?.
    50: 00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00 ........?.......
    60: 00 00 00 00 00 00 00 00 00 00 00 00 00 7f 88 88 .............???
    70: 2b 2c e4 00 00 00 00 c5 00 01 00 00 20 00 00 00 +,?....?.?.. ...
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    a0: 00 00 00 00 00 1b 00 00 00 00 00 00 00 00 00 00 .....?..........
    b0: 1c 3a 14 08 25 00 18 00 ff 33 83 74 80 00 00 00 ?:??%.?..3?t?...
    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    d0: 00 43 94 07 60 f2 00 03 00 00 00 00 00 00 00 00 .C??`?.?........
    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    f0: 5f 55 42 39 36 30 00 00 00 00 00 00 00 00 00 00 _UB960..........

    It's a same.

    best regards,

    hosung shin.

  • Hi Hosung,

    Thanks for following up on this. Could you confirm if the FPD-Link should be locked during this testing? Register 0x4D should show if we're losing lock during this ESD event, and if the SER/DES are locked before/after the event, however it reads 0x00 in both of the register dups which you have shown above.

    One thing to keep in mind, these registers are port specific (RX port registers selected in register 0x4C), it could be helpful to look at the lock status of each RX port. The concern would be that if we are losing lock, it is possible that there is a gap in the MIPI data which is being sent over the link.

    Best,

    Thomas

  • Hi Thomas,

    Thanks your support.

    Our HW engineer is looking for a solution in another way, so I am to close this issue.

    best regards,

    hosung shin.