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.

Problem with the SERDESUR-65USB DemoBoard from TI

Hi,

I have a Controller Board with the T20 (Cortex A9, Windows EC 7) connected to an 5,7" VGA Display with the parallel Inteface ==> this works fine.

Then I have connected the two SERDESUR-65USB Boards between the Controller Board and the Display. The LCD displays with some flickering pixels.

The PASS and the LOCK output of the DS90UR906 shows errors. I tried with the De-Emphasis Option, but without success.

The VDDI voltage is 3.3V.

Any idea ?

Thanks & best regards

Thomas

  • Hi Thomas,

    A few questions:

    1. What is the target pixel clock frequency?
    2. What is the cable used between the 905 and the 906 boards? Length/type?
    3. Can you elaborate on what STRAP pin settings are being used?
    4. You say the LOCK and PASS pins are showing errors: Is the LOCK LED blinking, or constantly off. Also, is the PASS pin showing errors when you run BIST?
    5. Without the video source (controller board) connected, will the SER and DES lock to each other?
  • Hi Ryan,

    1. the PixelClock is 25.175MHz
    2. it's the cable from the DemoKit (miniUSB)
    3. I have made no settings at the STRAP pins
    4. at the LOCK output I measure with an Oscilloscope and it "blinks". I measure this, because when the bridge on JP18 is build in, the LOCK out gets down to 2.0V (for 3.3V VDDIO there is no resistor for theLED)
    5. I don't know, is this testable without an clock ?

    Thanks & best regards

    Thomas

     

  • Hi Thomas,

    Thanks for the update. Item #5 doesn't matter - I was thinking of a different product. A couple suggestions:

    1. Try a shorter USB cable if you have one on hand. This might help identify if we're close to the signal integrity margin
    2. Try running the system without the display attached. Does LOCK stay constant HIGH now? I have seen display TCONs glitch the STRAP pins so let's remove this item as a variable.
    3. Can you read back registers 0x00 through 0x04 from the I2C interface? This might help identify or reinforce #2 above.
  • Hi Ryan,

    1. I tooked a very short cable, with no difference

    2. I disconnected the display. The LOCK appears in exactly the same way as before.

    3. Not tested till now

    Questions:

    What must happen exactly, that the LOCK error appears ?

    How much time elapse when the error appears, till the LOCK Pin shows the error (goes down)  ?

    Is it a problem, when the CLK propotion isn't always exactly 50%/50% ?

    Best regards

    Thomas

  • Hi Thomas,

    Since changing to a very short cable did not seem to fix things, I suspect an issue with the pixel clock. What is your source? I suggest trying to drive the PCLK pin with a function generator or similar device to note the difference.

    The LOCK error appears when the internal CDR circuit of the deserializer has lost recovery of the input data stream and embedded clock. This can be caused by a number of things ranging from excessive loss or disconnection of the cable, jitter in the input clock, or stopping the input data/clock. The error should take approximately t_xzd (see datasheet) to appear, but that could vary.

    The preferred duty cycle is 50%, but the datasheet does specify a 0.4/0.6 min/max for PCLK high/low time. If the PCLK duty cycle is changing, then you may have excessive jitter. 

  • Hi Ryan,

    the pixel clock source is an Controller Modul from Toradex (controller is an Tegra 2 from NVIDIA). I connected an external clock source with 25MHz, and the LOCK don't appear.

    So, now it's certain that the problem is generated by the pixel clock. I think it could be an jitter on this signal. 

    Is the time window known, from the point where the real error occurs till the LOCK out switch his state ?  

    Best regards,

    Thomas

  • Hi Thomas,

    Just so I understand correctly - you applied an external clock source at 25MHz and the LOCK pin on the UR906 eval board read constant high level? Or is it now constant low level? If the former, then I would agree that there is likely a jitter issue on the clock received from your controller module. If the latter, then maybe we are looking at some other configuration issue.

    It may be difficult to pinpoint a single error in time from the clock. However, the UR906 CDR will drop Lock (drive LOCK pin Low) if there is a corruption of the embedded clocking in the high speed stream. Roughly speaking, we could say this corresponds to the flight time in the cable (a few ns) and the serializer delay time (time from data shifted in, to data leaving from the serialized interface). See the parameter t_SD on page 15 of the DS90UR905 device datasheet.

  • Hi Ryan,

    So, the LOCK error didn't appear now ==> I build in an other uController modul. The first modul must have a problem on the pclk line (jitter).

    Unfortunately not all problems are solved, there are some flickering-pixel on the display. I found out, that the ground connections have an big influence to this flickering pixels, but I haden't have found a grounding mode where no flickering appears. Are there some recommendations about the ground connection method ? 

    Thank you very much and best regards

    Thomas

  • Hi Thomas,

    Do you have any pictures or schematic information that you can share? Which ground connections are you changing (display, cable, etc)?

  • Hi Ryan,

    Here a simple sketch about the test setup:

    The connection "LCD Data parallel" is done by an adapter board from ES&S (flatcable to ffc converter).

    With this test setup I have this pixel flickering, when I connect an cable from GND to VSS of JP17, the flickering is reduced, but it is still exist.

    I have to build up the test setup, then I will send you two pictures about what the display shows.

    Best regards

    Thomas

  • Hi Ryan,

    I have changed the Power Wiring as shown at the next picture.

    With this setup, I have much less pixel flickering.

    The wiring between your DemoBoard and the display is approximately 8 - 10 inch and there are three connectors in this line ==> could this be the problem ?

    An other question: can I use the i2c bus at the DeSerializer also for other slaves, like a touch controller ?

    Best regards

    Thomas

  • Hi Ryan,

    I Have analyzed our PCB and found following issues:

    1. on the connection between the DeSerializer and the Display Connector are four via's
    2. there are two Display connectors ==> one open fanout
    3. the lengths of the connections from the DeSerializer to the connector have not the same length

    Are this issues potenzially problems ?

    Best regards

    Thomas