• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 301 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: CRC error detect

DS90UB947-Q1: DS90UB947-Q1

Valerio Turrioni
Prodigy 10 points
Part Number: DS90UB947-Q1
Other Parts Discussed in Thread: DS90UB948-Q1, ALP

Hi all, thanks for support.

I wanted to ask you for some technical information about the CRC of the FPD-III link between the DS90UB947-Q1 serializer and the DS90UB948-Q1 deserializer.

 
For diagnostic purposes, we need to monitor the status of the video link between the controller and the display to see if it is affected by various problems. For example, Hardware problems but also Software or even Integration/System problems.

 
We had observed that, when starting our ECU linked to DISPLAY via ronseberger (fakra Twisted Pair cable Dacar 535), CRC errors (7,8,9 ) are counted in the first few minutes of link operation.

The same behavior can be observed if we use the 947 serializer EVB to connect our display and if we use the 947 serializer EVB connected to 948 deserializer EVB. 

The registers we monitor are 0x0A, 0x0B, 0x0C and 0x1B.

 
Therefore, we have some questions that we would like to submit to you:
 

1. What is the physical meaning of these registers?

2. What is the physical meaning of these CRC errors?

3. If we have a CRC error at Runtime, would there be ways to figure out what really happened to the link?

4. Are there other fields/registers that with certainty tell us that the link has experienced a failure in the forward channel video stream?

5. Is it possible to statistically characterize the FPDIII link with BER?

6. Are there external Texas tools and instruments to numerically evaluate the BER of our interconnect system?

7. Are the CRC errors that are present after the initial link startup due to initial tuning between ser and des that are self-adjusting with equalization?

8. Are there any known efficient ways to keep under control the state of the link and diagnose its operation as consistently as possible?


In the tests conducted, about 30 min after the system was started up, the above-mentioned registers were cleared, and these errors did not occur again throughout an entire morning. We wondered if there is some sort of guard time after which we can consider the information content of the monitored registers reliable/significant?

Should equalization be done periodically over time could we incur CRC errors during normal operation?

Thanks and best regards.

  • 0
    TI__Mastermind 25765 points

    Hi Valerio,

    I will put together answers for your questions and get back to you in 1-2 business days. Thank you!

    Regards,

    Ben Dattilo

  • 0 in reply to Ben Dattilo
    TI__Mastermind 25765 points

    Hi Valerio,

    To answer your questions:

    1. Registers 0xA and 0xB count the number of CRC errors that occurred on the back channel. These registers will show CRC errors for Port 0 or Port 2 depending on which port is selected in the Port Select Register. Register 0x0A shows the LSB of the total number of reported CRC errors, while 0x0B shows the MSB of the total number of reported CRC errors. These registers are cleared by 0x04[5].
      1. Register 0x0C is the General Status register which has useful information when it comes to monitoring the status of the link (see datasheet for bit descriptions).
      2. Register 0x1B is a CRC counter for the BIST function.
    2. The cause of the CRC errors could be several different things. In general, CRC errors mean errors occurred on the backchannel (948->947 communication). This could mean some accidental changes to the data sent over the channel caused by some disturbance such as noise, reflections, cross talking, etc. It is fairly common to see these at start up as you described.
    3. There are several diagnostic option you can use to monitor the link. The most straightforward would be to monitor the Link Detect bit of the General Status Register 0x0C. This will show the link status of the selected port.
    4. The General Status Register shows the status of the link in the LINK detect bits. The DUAL_STS register (0x5A) also shows whether link has been established, and shows whether the receiver is LOCKED to the transmit clock. See datasheet for bit descriptions.
    5. You can monitor the CMLOUT loop-through output on the DES, this is essentially the forward channel without the backchannel so you can monitor the eye of the channel.
    6. Not specifically for BER, but we do have a Margin Analysis tool in ALP that can be used on the 948 side.
    7. As I mentioned before, there are many reasons that CRC errors could be occurring, and while it is common to see these on start up, it is always best to have a link with no CRC errors.
    8. Other than the tools I have discussed above, BIST is another diagnostic tool that can be used. BIST is an optional At-Speed Built-In Self Test (BIST) feature supports testing of the high-speed serial link and back channel without external data connections. This is useful in the prototype stage, equipment production, in-system test, and system diagnostics.

    In short, these CRC errors may not be serious, but it is recommended to make sure the link is stable as you have described. A few basic checks you may want to do on your system include:

    • Make sure to follow the Power-up Requirements outlined in the datasheet
    • Make sure MODE_SEL1 is strapped to the correct mode (specifically in this case if you are using a coax cable, make sure COAX = 1, otherwise COAX = 0)
    • Make sure the design recommendations we have laid out in the datasheet are properly implemented in your design (for example, the power rail decoupling scheme)

    Regards,

    Ben