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.

TI LVDS Receiver IC (DS90CF384) internal fail safe circuitry

Other Parts Discussed in Thread: DS90CF384, SN65DSI83

Hello Team,

I have a customer who is having issues with the DS90CF384 and wants to verify if the internal fail safe circuitry of this device is causing an overall failure of the product/ system. The description is below:

Can you clarify the type of fail-safe circuit the DS90CF384 has? In the application note it mentions a few types. TI seems to have two fail-safe circuit configurations – the type shown below and also a Window Comparator. 

Based on the information I put together –  the DS90CF384 is compliant with TIA/EIA-644 LVDS Standards. This means it has fail-safe functions implemented with  internal pull-ups on each signal of the differential pair as shown below. My customer is trying to understand if it is possible for the inputs of this LVDS receiver to over-load the outputs of the device driving it? My understanding is once a valid signal is present on the differential input to the LVDS receiver it would not be possible to “lock-up” the device that is driving these valid signals. Can you confirm this?  

Below are parts of schematics ( will be emailed separately ) showing the MIPI-DSI Bridge to LVDS (SN65DS183ZQER) part my customer is using. Also shown to the far right is the LVDS receiver on the Sharp LCD PCB. What I would really like to understand is if there is any way the LVDS receiver on the Sharp display PCB can cause the LVDS outputs (of the MIPI Bridge) to all of a sudden stop working properly? Once power is cycled everything works properly again. At the time of the MIPI bridge LVDS output failure there is nothing being done to the system. It is just sitting on a test station powered on and displaying the home screen. 

Any insight you can provide is appreciated.


 

 

Let me know where to email the schematics.

Thank you for your time and attention towards resolving this issue.

Kishen

  • Hi Kishen,

    I will need to do some digging to figure out if we implement an internal fail-safe for the DS90CF384. I was unable to find mention of an internal fail-safe for the DS90CF384, so users may need to provide the external fail-safe circuitry externally. In the past, I have seen customers do this, especially on the LVDS clock, in order to avoid the DS90CF384 inputs mistakenly passing large exceeding the minimum signal threshold as data. I just probed one of our EVMs with a similar deserializer device at the RxIN pins and no signal applied. It is showing a high resistance to both Vcc and GND, which leads me to think that there is no internal fail-safe circuitry.

    May I ask which application note the customer is referring to in order to determine whether we have an internal fail-safe circuit?

    With that having been said, I am not familiar with a situation in which the deserializer "overloads" the device outputs that are transmitting into the deserializer. The 100-ohm termination at the RxIN inputs should be the only load, and it should match the characteristic impedance of the traces/cable connecting the deserializer to the LVDS source.

    Please send the schematics to: m-lu (at) ti (dot) com

    I will take a look at them and get back to you with some additional thoughts.

    Thanks,

    Michael

  • Hello Micheal,

    Thank you for your attention towards this post. I really appreciate it.

    I believe the DS90CF384 is compliant with TIA/EIA-644 LVDS Standards as mentioned in the datasheet ( 3rd last point under features). This means it has fail-safe functions implemented with  internal pull-ups on each signal of the differential?

    Customers follow up

    "My customer is trying to understand if it is possible for the inputs of this LVDS receiver to over-load the outputs of the device driving it? My understanding is once a valid signal is present on the differential input to the LVDS receiver it would not be possible to “lock-up” the device that is driving these valid signals. Can you confirm this?"

    I have sent the schematics to your email. Any insights would be really appreciated.

    Thanks

    Kishen

  • Hi Kishen,

    It is important to note that there is a difference between "compliant" and "compatible." According to the datasheet, the DS90CF384 is "compatible" with systems that implement the TIA/EIA-644 LVDS standard, but this does not guarantee that the device is "compliant" with all TIA/EIA-644 LVDS standards. My understanding from looking at the TIA/EIA-644 standard I have is that there is no specific requirement for fault detection circuitry and that the implementation is beyond the scope of the standard. With that having been said, I am happy to look at documentation that implies otherwise in order to see where the customer is coming from.

    I do not believe it is possible to lock up the device driving the signals to the DS90CF384. However, I do have a question about whether the signals are being received appropriately based on the schematic you provided me. On the receiver, I do not see any 100-ohm differential terminations across the RxIN+/- or RxCLKIN+/- inputs. These differential terminations are critical for proper LVDS signaling, and if the LVDS differential signals going into the DS90CF384 are not terminated, these signals will be reflected back at the MIPI-DSI bridge device.

    Thanks,

    Michael
  • Hello MIchael,

    Thank you for looking into the schematics of the customer. The confirmed there are 100 ohm termination resistors at the differential inputs of the LVDS receiver. Please see the picture of the LVDS receiver on the PWB ( emailed to you) . Circled in purple the resistors near the receiver inputs and also the resistor instance names are silk-screened on the PCB to the right of the IC. A better schematic showing these resistors will be sent as soon as it is made available , but the customer has physically confirmed they are on the PWB and associated with each differential input on the receiver. This brings us back to customers main question here , “what is going on in the MIPI to LVDS bridge that would arbitrarily (seemingly) cause some of the outputs to the LVDS receiver to stop working properly?”

    Thank you very much for looking into this.

    Kishen
  • Hi Kishen,

    Thanks for the confirmation. It's always good to have a sanity check. I still am unable to think of something obvious that would cause this issue to occur. I got a few requests/questions to help debug:

    1. Can you connect a separate, known good power supply to the MIPI-to-LVDS bridge and see if the issue keeps occurring? I want to know if this issue follows the transmitter or the receiver device.

    2. Is this issue pattern-dependent, meaning that it only occurs when the source sends a particular pattern? Or does this issue happen all the time?

    3. Has the customer tried swapping out the DS90CF384 ICs to see if replacing the IC fixes the issue?

    4. Can the customer provide scope shots by probing across the 100-ohm differential termination so that I can view the signal quality of the LVDS signal going into the DS90CF384?

    Thanks,

    Michael
  • Hello Michael,

    Thank you for the suggestions. I did put them forward to the customer and he replied as below:

    "Please see my replies below but currently we still do not understand the cause of this random but very rare occurrence. Please understand that the blank screen events have occurred only a dozen times and only on about 6 units out of ~300 units that have been built up. We currently cannot force the blank screen event to occur in the system.  It just randomly happens so we wait for the next blank event to happen and when it does we measure the outputs of the MIPI to LVDS bridge and find some of the LVDS outputs are not valid (almost seem tri-state but this is not proven).

    1. Can you connect a separate, known good power supply to the MIPI-to-LVDS bridge and see if the issue keeps occurring? This would be difficult to do as the blank screen occurs randomly and may take weeks or months to occur again. I want to know if this issue follows the transmitter or the receiver device. At this time I suspect the issue is the transmitter (the MIPI to LVDS device) since we measured the outputs on a unit that developed a blank screen and found 3 LVDS lanes were not functioning properly. However once the unit was power cycled it was working properly again.

    2. Is this issue pattern-dependent, meaning that it only occurs when the source sends a particular pattern? Hmmm.. not sure but I believe the display is not changing content but I will check. Or does this issue happen all the time? The issue happens rarely and we cannot force it to happen. When it has happened we try to leave the unit powered on and measure the signal chain. That is when we noticed that the LVDS outputs on the MIPI to LVDS device were not outputting valid data signaling.

    3. Have you tried swapping out the DS90CF384 ICs to see if replacing the IC fixes the issue? The MIPI to LVDS bridge IC is on the main controller board which is not part of the display. The LVDS receiver (DS90CF384) is on the PCB inside the LCD display. The controller board connects to the LCD display through an LVDS cable.

    4. Can you provide scope shots by probing across the 100-ohm differential termination so that we can view the signal quality of the LVDS signal going into the DS90CF384? I will try to get this done.


    Thank you for your continued support with this. I will update you as soon as we have more.

    Sincerely,

    Kishen

  • Hi Kishen,

    From this description, it seems like this issue could possibly be related to some sort of random instability since it is not repeatable. I think it may potentially be linked to a noisy power supply for the transmitter SN65DSI83 device or even a device preceding the bridge. I am starting to believe that this is not an issue based in the DS90CF384.

    While the customer gets data, I suggest also reaching out to the Dallas HSI team (perhaps try Joel Jiminez) to see if they have seen this behavior before from their transmitter.

    Regards,

    Michael