• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 34 subscribers
  • Views 391 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.

DS90UB954-Q1: FPD3_ENCODE_ERROR

Jeffrey C
Prodigy 60 points
Part Number: DS90UB954-Q1
Other Parts Discussed in Thread: DS90UB960-Q1, , DS90UB953-Q1
We are working with the 953/954 SERDES pair from TI. To the best of our knowledge, we have measured voltages and currents and they are within the specifications of the SERDES data sheets.
We have our system setup as shown in the attached figure:
TI_954_DES_Question.png
We are observing CSI RX errors in the 954 deserializer and no corresponding CSI errors reported in the 953 serializer. The errors observed are in the figure above, namely FPD3_ENCODE_ERROR and CSI ERRORs.
The questions we have are:
Question 1): Does FPD3_ENCODE_ERROR result in CSI Errors or do CSI Errors results in FPD3_ENCODE_ERROR?
Question 2): What would cause these errors observed in the deserializer when SERIALIZER CSI Error Register reads show no errors on the transmit side?
Question 3): What is suggested to further debug these issues? Are there any documents you can point to or suggestions on what to look for in our system and/or PCB design?

These errors appear intermittently after running many frames, but occur often enough in time in our system that it is making it unreliable. We run two modes in our system and encounter these errors in both modes. The MIPI link data rates are approximately 480Mbps (Mode 1) and 160Mbps (Mode 2).
Would appreciate any suggestions you could provide. 
Kind Regards,
Jeff
  • 0
    TI__Guru** 103215 points

    Hello Jeff,

    Can you please repost your picture? It did not show up.

    Best Regards,

    Casey

  • 0 in reply to Casey McCrea
    Prodigy 60 points

    Hi Casey,

    Attached is the image.

    Kind Regards,

    Jeff

  • 0 in reply to Jeffrey C
    TI__Mastermind 18755 points

    Hello Jeff,

    Question 1): It sounds like since the serializer appears to be working properly and the deserializer is seeing errors that the problem is somewhere in between the SERDES pair. With that being said it is rather difficult to know what exactly may be causing the errors to occur.

    Question 2): It really sounds to me like the problem is going to be related to the connection between the 954/953. If the data is transmitting fine but not being received properly it may be a faulty connection.

    Question 3): My first thought is that the cable and connections are causing information to be lost. I would first suggest using the Built in Self-Test (BIST) to see if you can troubleshoot why the errors occurring. More information can be found in the datasheet section 7.5.12. If you are still having issues after that, then I would suggest using the Margin Analysis Program (MAP) that is included with our Analog Launch Pad software. This will allow you to find the best EQ and strobe position combination that will yield the fewest errors. Here is a link to see how to use the software http://www.ti.com/lit/ug/snlu243/snlu243.pdf.

    Finally I am curious if there are any differences in the amount of errors when running in the 480 Mbps mode vs the 160 Mbps mode? And what length of cable are you using?

    Regards,

    Nick

  • 0 in reply to Nicholas Darash
    Prodigy 30 points

    Thanks Nick,

    In terms of cable/connection issue, I was checking parity error from deserializer register 0x55, 0x56 and back channel CRC error from serializer register 0x55, 0x56. None of the registers have increased. However, we did see 'Lock_sts_chg' bit from (954) 0x4D register. Is that possible that link gets lost while parity error/back channel CRC error counter remains zero?

    Kevin

  • 0 in reply to Kefan Hu1
    TI__Mastermind 18755 points

    Hi Kevin,

    It depends on when the registers are read.  Registers 0x55 and 0x56 give then the count of parity errors since the last detection of a valid lock, if lock is lost then the parity error count registers are cleared.  So if the registers are read and lock is not established, or was very recently established, then they may read zero.  

    Regards,

    Nick

  • 0 in reply to Nicholas Darash
    Prodigy 30 points

    Got it.

    Right now we are trying different setup. One interesting thing we found is that if back channel frequency is set to 25mhz instead of 50mhz, then no error shows up...

    The system is running at CSI-2 synchronous mode. On the 953 datasheet it mentions:  "For operation with the DS90UB954-Q1 or DS90UB960-Q1, the back channel should be programmed for 50-Mbps operation in DS90UB953-Q1 Synchronous mode".

    I am wandering what's the drawback of setting a lower back channel frequency. I understand with lower clock the CSI-2 throughput has been limited, but is there any other potential issue?

    Kevin

  • 0 in reply to Kefan Hu1
    TI__Mastermind 18755 points

    Kevin,

    So basically your spot on, the forward channel-frequency is derived from the back-channel frequency. If you are changing the back-channel frequency from 50MHz to 25MHz than the forward channel frequency will be halved. Now the reason for fewer errors is because of the lower frequency. So this points to some signal integrity issue in the link. Now if your system can still get the required throughput at that frequency, you should be fine to use it. But, I would recommend finding the issue with the channel itself and keep the frequency at 50MHz if you intend to run at 4Gbps.

    Regards,

    Nick