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.

DS90UB953-Q1: Internal termination resistors appear to intermittently fail

Part Number: DS90UB953-Q1
Other Parts Discussed in Thread: AWR1243BOOST, AWR1243

We're observing that the DS90UB953-Q1 appears to fail to engage the internal termination resistors intermittently when input data is transmitted at 300 Mbps.  When this occurs, the differential voltage increases from 200mVpp to 400mVpp due to the reflection caused by the unterminated line.  This appears to be the similar to the issue reported here https://e2e.ti.com/support/interface/f/138/t/707177?DS90UB953-Q1-Data-Voltage-Variations

Why is the DS90UB953-Q1 failing in this way?  How do we ensure it receives data correctly?

 


In the plot below the Channel 1 (yellow) is the CSI clock, and Channel 2 (green) is CSI data lane 0.


This image below shows a successful transition from LP to HS mode, while the second shows a failure in this transition where the internal termination appears to be turned back off just after -179 ns.

Why is the DS90UB953-Q1 doing this and how do we ensure it terminates correctly?

Thank you,
Christopher

  • Hi Christopher, 

    Does this problem only occur when you are running at 300 Mbps? If you change the rate, does this have any affect? Does this happen to all the data lanes?

    Also, if register 0x02 [6] set properly? Are you making sure that you are telling the 953 if you are using continuous/non continuous clocking? 

    Thanks, 
    Sally 

  • Hi Sally,

    We've tested this problem for this board at 300, 450, and 600 Mbps.  450 and 600 Mbps work fine, however for this board we observe this issue at 300 Mbps.  

    Below are eye diagrams of multiple packets at 300, 450, and 600 Mbps respectively.  450 and 600 are clean, while 300 Mbps is characterized by a double eye, showing the DS90UB953 does not terminate for some of the HS transmissions.

    300 Mbps:

    450 Mbps:

    600 Mbps:

    I will check our configuration for register 0x02 bit 6

    Christopher

  • Hi Christopher, 

    Can you also check registers 0x5e - 0x60 ? This will check the CRC and CSI errors. 
    Looking at your waveform, is this AC coupled because the Vcm is 0V, but it should be .2V. Also when it in LP mode, is the voltage around 1.1/1.2V? -> Can you check these values at the output of the camera? 

    Thanks, 

    Sally  

  • Hi Sally,

    When we checked the CSI error registers previously, we found that there were SOT errors in 0x5E-60.  Also we are not AC coupled.  The camera is actually the AWR1243BOOST.  We are unable to test the values at the output of the AWR1243 boost as there are no provisions to do so.

    Christopher

  • Hi Christopher, 

    Can you check with the team that supports your BOOST board as to why the Vcm is around 0V? It may or may  not be contributing to a SoT error. We should first make sure the signal is proper because right now, the signal does not appear to be matching MIPI CSI-2 v1.2 standards. Also, please ask that team if it's possible to blue wire somewhere on the board to check the signals. 

    Thanks, 

    Sally 

  • Hi Sally,

    Vivek has pointed out that since the scope traces I've posted above are captured with a differential probe, Vcm is cancelled out since the trace is referenced to the negative diff probe input--not ground.  Vivek advises that Vcm is 200mV and that LP mode voltage is ~1.1 - 1.2V.

    His response can be seen here: https://e2e.ti.com/support/sensors/f/1023/p/925118/3419381#3419381

    Christopher

  • Hi Christopher, 

    I will need a few days time to investigate into this further. In the mean time, please see if it's possible for you to probe the signal at the TX output instead of the RX input. I will get back to by later next week. 

    Thanks, 
    Sally 

  • Hi Christopher. 

    Can you please probe single ended? When you check the MIPI D-PHY protocol, it does not look like the TX is following proper high speed transmission protocol. From -379ns to -179ns there is a weird step transition why does not look typical. Can you probe the data lines and get a screen shot like this please? Also, please capture the high speed transmission sequence for both the working data rate and the not working data rate. 

    Thanks, 
    Sally 

  • Hi Sally,

    The screenshot you sent did not come through in your post.  However I have scope captures of the single ended signals.

    The weird step transition you are calling out is what I suspect the issue is: It would seem to me that step transition is where the DS90UB953-Q1 disables the internal HS-mode termination.

    This scope capture shows a short packet LP->HS transition correctly terminated and a long packet LP->HS transition incorrectly terminated at 300 Mbps.

    The step transition is clearly visible at about ~1.68us.  After this point, Vdiff between the single-ended signals becomes 400mV instead of 200mV.

    This scope capture shows both packets correctly terminated at 450 Mbps.

    As you can see in this capture, there is no step transition and the HS Vdiff remains at ~200mV throughout.

    Christopher

  • Hi Christopher, 

    I see now that the PHY sequence follows protocol. I will need to consult my team internally and get back to you by early next week.

    Thanks, 
    Sally 

  • Hi Christopher, when you said the CSI rate is 300 Mbps, is that per lane? Also, if it's 300 Mbps per lane, can you lower the frequency down a little more and see if you are still having termination problems? 


  • Hi Sally,

    Yes, that is 300 Mbps per lane.  I will see if I can test a lower speed, however I need to reiterate that we have no problems at 450 Mbps nor 600 Mbps.  For this board, both of 450 and 600 Mbps work perfectly fine.  (I posted plots showing those clean, properly terminated eye diagrams on July 9: https://e2e.ti.com/support/interface/f/138/p/921679/3404906#3404906

    Christopher

  • Hi Sally,

    Please see attached plots showing the same failure at 225 Mbps and 100 Mbps.  As you can tell by the eye diagrams, the failure is intermittent.  Some packets are terminated correctly and others are not.  This gives the dual-eye structure where there are two superimposed eyes with different amplitudes.

    225 Mbps

    100 Mbps

    Christopher

  • Hi Chris, 

    Thank you for the new info. I didn't realize it was an intermittent before. Can you please run one more test case scenario for me? Can you run you run at 80 Mbps and let me know what the voltage is at for these pins: 25, 16 11? Please measure those right at the pin. 
    Also, for 300 Mbps, can you please try setting register 0x2E  = 0x81 and increment the last 4 bits [0:4] by 1 each time until you reach 0x2E = 0x8D? Also please change this register before sending CSI-2 data. 

    Do you have multiple 953 devices that you are testing ,or is this all on one device? 


    Also, let's continue this discussion via email  . s-cheung@ti.com . Please send further updates to my email.

  • Hi Sally,

    Yes, this issue intermittently affects packets at some random percentage.  As you can see from the very first screenshot I included in the original post, some of the packets are terminated correctly (400 mV peak-to-peak) and some are not (800 mV peak-to-peak).  It is also possible to see the 953 behaving in the same way as observed by Antonio, another e2e user in his post that I linked, which is from July 2018: https://e2e.ti.com/support/interface/f/138/t/707177?DS90UB953-Q1-Data-Voltage-Variations

    In Antonio's scope capture, you can see some packets terminated (correct voltage swing) while others on the scope are unterminated (double voltage swing).

    I am unable to run at 80 Mbps, as 100 Mbps is the lowest the AWR1243 supports.

    I am away from the lab this week, I will see if a colleague is available to try this test.  Otherwise I can try this when I return.

    We do have multiple 953 devices of this design, all of them that we have tested exhibit this same failure.

    I will send you this via email as well so we can also discuss there.

    Sincerely,

    Christopher

  • Hello Christopher,

    Since this discussion is moving to email, we will plan to update the thread status when the issue is resolved 

    Thanks,

    Casey