DS90UB960-Q1: unstable FPD link lock

Hi Aviad, 

I'm currently looking into this and will provide a response to your questions within the next 24 hours. 

Regards,

Kenneth

Hi Aviad,

Thank you for your patience.

From the register values that you have provided, it looks like the "LOCK" status of the deserializer is unstable throughout the operation of the device. One reason why LOCK could be unstable is the way in which the device is connected in the schematic. For the device to operate as expected, our recommendation is to follow the application schematic in Section 8.2 of the DS90UB960-Q1 datasheet. Could you please share the schematic of the DS90UB960-Q1 in the design, so I can see how it is connected?

Additionally, in the register data that you provided I noticed that the FREQ_STABLE bit is continuously changing, which means that something could also be wrong with the clock signal on either the deserializer side or the serializer side. What clock mode is the DS90UB953-Q1 configured for? Is it configured for synchronous mode, or is it configured for a different mode?

Regards,

Kenneth

Hi,

Thanks for the response.

1.

I attached the schematics of our design, and also the specification of the connectors.

Is there anything wrong with our design?

2.

The input to the  953 mode pin is configured to CSI-2 Synchronous mode.

[R_h=open, R_l=10K]

3.

We try removing the POC, and it partially help -

For 50cm length cable there is stable FPD link.

But for 3m cable, the FPD LINK is very loose,

and for 5m cable no link is recognized.

For the 50cm cable, sometimes the CSI_ERROR flag is on (bit #3 of reg 4E).

What this mean?

Thanks

Hi Aviad,

Aviad Pedahel said:

I attached the schematics of our design, and also the specification of the connectors.

Thank you for providing the design files. I am assuming that the schematic is provided in the file with the ".DSN" extension. If this is not the case, please let me know.

Currently, I am having trouble opening ".DSN" files. Is there any way that you can you provide a version of the schematic that is in a ".PDF" file, showing the exact connections and components used in the design? This is the best way for me to analyze the design, since it will allow me to directly compare your design to our typical application schematic in Section 8.2 of the datasheet. 

If you do not want to post the schematic on a public forum, you can send me a direct message on E2E with a PDF file of the schematic attached. I have sent you a friend request on E2E. If you accept my request, you can then send me a PDF file of the schematic in a direct message. 

Aviad Pedahel said:

The input to the  953 mode pin is configured to CSI-2 Synchronous mode.

[R_h=open, R_l=10K]

Thank you for providing this information. The resistor configuration that you have given is correct for Synchronous mode.

Aviad Pedahel said:

We try removing the POC, and it partially help -

For 50cm length cable there is stable FPD link.

But for 3m cable, the FPD LINK is very loose,

and for 5m cable no link is recognized.

Is the register data that you initially provided for a cable length of 3m, or was it for a different cable length?

Also, when you say that "removing the PoC partially helped", what do you mean by this? Did removing the PoC reduce the number of errors for only one of the cable lengths, or did it reduce the number of errors for all of the cable lengths?

Aviad Pedahel said:

For the 50cm cable, sometimes the CSI_ERROR flag is on (bit #3 of reg 4E).

What this mean?

To understand why this flag was set for the 50 cm cable, we need to check and see what bits are set in the CSI_RX_STS Register (Register Address 0x7A). Could you please provide the value of this register whenever the CSI_ERROR flag is set?

Regards,

Kenneth

Hi Aviad,

Thank you for providing the schematic in a .PDF file format. Please allow me until this Wednesday to look over it and provide feedback.

Regards,

Kenneth

Hi Aviad,

I was able to look over the schematic that you provided today. Here is my feedback:

- I noticed that you are using pull up resistors on the I2C bus that are higher than what we recommend. If you have already tested the design and the I2C bus functions as expected, then it is good as is. If you have not yet tested the design, please consider using lower resistance values for the pull up resistors (such as 4.7 kΩ, for example) so that the bus can operate with a faster data rate.

-Is the PDB_des4 signal connected to an MCU that is driving the PDB pin low until the power supplies connected to the device reach their minimum values? This is a part of the power sequencing requirements for this device. 

-For the VDDL1, VDDL2, VDD_FPD1, VDD_FPD2, VDD_CSI0, VDD_CSI1, VDD18_P0, VDD18_P1, VDD18_P2, VDD18_P3, VDD18_FPD0, VDD18_FPD1, VDD18_FPD2, and VDD18_FPD3 pins, make sure that there is either a 0.1 µF capacitor or a 0.01 µF at each individual pin. Additionally, some of the capacitors being used have different values and are in a different configuration from what is recommended in the datasheet. Our recommendation is to follow the capacitor configuration given by the typical application schematic in Section 8.2 of the datasheet.

After reviewing the schematic, I'm not seeing anything in the schematic alone that would cause the "LOCK" status to be unstable for different lengths of cable. The loss of the "LOCK" status for different cable lengths suggest that something in the design is causing there to be a large amount of insertion loss. Large insertion losses can either be caused by the type of cable being used to transmit the FPD-Link III signal, or the layout of the design. 

What is the name of the 3 meter and 5 meter cables being used? Are you able to provide access to the datasheet of the cable being used, so that I can view the specifications?

For the layout of the design, please allow me until this Friday to review the layout and provide feedback on the design. 

Regards,

Kenneth

Hi Kenneth,

Update:

We thought that this is issue of the REFCLK.

When we changed to external REFCLK with 22.05MHz,

all works fine !!

22.05 is below the rated requirement - 23-26MHz ...

Moreover, the system is very sensitive to the frequency.

little deviation from the 22.05 value (e.g. 22.15) and again the LOCK is unstable.

[the ub960 report on 25MHz , Reg A5 value is 0x19 , although we measure 22.05...]

{Also, we try a REFCLK source device that works well [outputs 25MHz] on other board,

and the problem exist !.}

Does this indicate something ?

I also attaching the cable spec.

cable spec

Below are remarks from our HW engineer.

- I noticed that you are using pull up resistors on the I2C bus that are higher than what we recommend. If you have already tested the design and the I2C bus functions as expected, then it is good as is. If you have not yet tested the design, please consider using lower resistance values for the pull up resistors (such as 4.7 kΩ, for example) so that the bus can operate with a faster data rate.
OK. but this is not the issue.
Or, does it have any effect on the FPD link / mipi ?

-Is the PDB_des4 signal connected to an MCU that is driving the PDB pin low until the power supplies connected to the device reach their minimum values? This is a part of the power sequencing requirements for this device. 

We operate it this way.

Regarding the scheme:

That is correct.
but inspired by the two reference designs provided by TI, we did exactly as those designs (snlu226b + TIDRTR6)
so which way t pick ?  the functional & practical examples, or the one from the datasheet ?  

. After reviewing the schematic, I'm not seeing anything in the schematic alone that would cause the "LOCK" status to be unstable for different lengths of cable. The loss of the "LOCK" status for different cable lengths suggest that something in the design is causing there to be a large amount of insertion loss. Large insertion losses can either be caused by the type of cable being used to transmit the FPD-Link III signal, or the layout of the design.
we use for reference a 16ch camera system which we bought,
those specific cameras and specific cables works fine.

Bad Layout will definitely cause problem.
But what is the explanation for “fool” the REFCLK and get a stable FPD link,  If the layout is wrong ?
bad layout will never achieve stable result.

Thanks

Hi Aviad,

Thanks for providing an update.

Can you please resend the CAD files that show the layout of the design? I am currently unable to access them using the link that you originally sent me. If you want, you can send me a private message on E2E with the files attached.

Aviad Pedahel said:

OK. but this is not the issue.
Or, does it have any effect on the FPD link / mipi ?

I don't think the pull up resistors are having any impact on the issues that you are encountering with the device. I pointed them out in my schematic review to provide general feedback on the design.

Aviad Pedahel said:

-Is the PDB_des4 signal connected to an MCU that is driving the PDB pin low until the power supplies connected to the device reach their minimum values? This is a part of the power sequencing requirements for this device. 

We operate it this way.

Thanks for confirming that all power sequencing requirements are being followed. 

Aviad Pedahel said:

That is correct.
but inspired by the two reference designs provided by TI, we did exactly as those designs (snlu226b + TIDRTR6)
so which way t pick ?  the functional & practical examples, or the one from the datasheet ?  

The configuration of the capacitors in your design is okay. I initially thought that I saw some different capacitor values being used when I conducted my initial schematic review. 

Aviad Pedahel said:

Bad Layout will definitely cause problem.
But what is the explanation for “fool” the REFCLK and get a stable FPD link,  If the layout is wrong ?
bad layout will never achieve stable result.

It is possible that the layout may not be optimized to support high speed transmissions, which may be why were able to achieve a stable FPD-Link whenever you switched to an oscillator that is operating at a lower frequency. What are the resolution, frame rate, and data type specifications of the camera that is connected on the serializer side? 

As previously mentioned, please resend the CAD files showing the layout of the design so that I can provide feedback. I still think that insertion losses resulting from the layout may be the primary cause for the unstable lock status. 

Regards,

Kenneth

Hi Aviad,

Thanks for providing the layout files. I will work to provide feedback on the DS90UB960-Q1 layout by next Tuesday. If possible, can you also private message me the .brd files that show the layout of the DS90UB953-Q1? The layout files that you sent only include the DS90UB960-Q1.

As previously mentioned, I believe that there is insertion loss in the design that is causing an unstable link connection. To determine the extent of this insertion loss, here are some tools and measurements that you can use:

To ensure the device operates as expected, there are specific channel specifications that need to be met. To assess the quality of your link, I recommend that you take all of the required channel measurements, and see if they meet the channel specifications. You can obtain the channel specifications for these devices by reaching out to your local TI representative. 

Another tool that you can also use to determine the quality of the link is the Margin Analysis Program (MAP). This is a program included in the analog launchpad development kit. Using this program, you can create diagrams that can help diagnose the condition of the eye diagram, and determine which combination of EQ levels and strobe positions show no errors or loss of lock. To help determine the current quality of the eye diagram in your design, I recommend that you run the Margin Analysis Program for the 5 meter cable. For information about how to use the Margin Analysis Program, you can refer to this application note: https://www.ti.com/lit/ug/snlu243/snlu243.pdf

Additionally, I also had a question about the cable specifications that you provided. Is this attenuation table in the cable specifications document for a specific cable length? If so, what cable length is it for?

Regards,

Kenneth