• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 171 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.

DS90UB914A-Q1: Interface forum

Kygo Cheng
Expert 6830 points
Part Number: DS90UB914A-Q1

Hi Team,

Cause the 914A flickering issue from my customer!

From bench feedback that can reproduce the 914A flickering issue when flickering FR914 chip with 914EVM, 6M COAX cable and oToCAM204 camera module.

And our EVM with  914A connect oToCAM204 camera module, the flickering will be reproduce ! But connect to another customer camera module would be OK! Regarding changing the camera of another customer, the flicking will disappear!

But we have another test to swap good 914A & fail 914A  with EVM, and  flickering will follow fail 914A !

So is there any way to verify that the customer’s oToCAM204 camera module does not meet our requirements? And then cause the flicking issue. The method I currently think of is as follows:

  1. Verify EVM with  914A connect oToCAM204 camera module have flicking but 914A EVM connect to 913 EVM will have not flicking, please refer below table

 

DES

SER

Result

1.

EVM with flickering 914A

oToCAM204 camera module

flickering

2.

EVM with flickering 914A

913 EVM (but 913 change to oToCAM204 camera module’ 913 )

Flickering or not
  • 0
    TI__Guru** 103215 points

    Kygo, 

    It seems to me like there is probably an SI issue between the SER/DES in the system design. It could be that the oToCAM204 design doesn’t meet the channel requirements or it could be that the 914A side doesn’t meet the channel requirements, or maybe both. There was a comment earlier in the thread that indicated using shorter cable makes the problem worse? This is a typical sign of a return loss problem in the PCB/connector/cable design which is why I think this is probably related to the PCB/connector. If you have a return loss issue at the PCB due to poor impedance control through either the layout or the connector of the PCB then this will cause reflections in the high speed signal path. If you have a shorter cable, then the negative effects of those reflections will have a bigger impact on the signal quality seen at the receiver of the 914A compared to if you have a long cable.

     

    Additionally you may want to check the PCLK or CLKIN jitter going to the 913A on the oToCAM204 module with the attached guide.

     

    What I would suggest to do here is to work with the customer to measure the return loss and TDR of the oToCAM204 FPD-Link signal path going to the 913A chip using the channel test procedure and verify if it is meeting our requirements from the attached channel spec. There is no spec for min VOD or eye mask on CMLOUT so that is not the right way to evaluate this. The zero crossing is strange but I suspect that is probably persistence from the initial startup, not something that if happening in steady state. If it is happening in steady state then there is definitely an issue there and it could be related to SI or to clock stability of the sensor input clock to the 913A or power supply glitch, etc.

     FPD-Link Transmission Channel Test Procedure_ver1p2.pdf

    Channel-Requirements-ADAS chipsets FPD III.pdf

    92x-91x Jitter_measurment_Sep2016.pdf

    Best Regards,

    Casey McCrea