• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 33 subscribers
  • Views 563 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.

DS92LX1621: Rescue communication to serializer if Signal Detect Status is 1 and LOCK Pin Status is 0

Ilario Gottardello
Prodigy 60 points
Part Number: DS92LX1621

Hello,

we are using these SER/DES with a CMOS that gets its clock from a programmable clock generator.

If it's not programmed, it will not output a clock, so serializer will switch to its internal clock and we are able to setup it.

But, we have a case where suddenly a working board started to not link correctly. We do not know why, maybe is a failed setup, maybe it's unrelated.

We can see that at register 0x1C of the deserializer, Signal Detect Status is at 1, so it sense something on the other end of the cable. It is never able to lock it however, and LOCK Pin Status is 0.

We would like to know if there is some method to force serializer to ignore PCLK pin and use its internal clock only, so to establish a link and having a working I2C again.

We already tried to reset the board and wake up the serializer as fast as possible, but it doesn't work (can't confirm if PCLK kicked in too fast).

We regularly program register 0x27 with E0 and we are using the wake up procedure as per datasheet.

Thank you very much for any suggestion.

Ilario Gottardello

  • 0
    TI__Guru** 107460 points

    Hello Ilario,

    please double check if both devices are powered up correctly and you have a stable power supply on both devices. Also please check you cable and make sure you do not have any unstable connection on the connectors for example.

    Have you tried different boards and different cables?

  • 0 in reply to Hamzeh Jaradat
    Prodigy 60 points

    Hello Hamzeh,

    yes, now I checked the boards and they are working fine. But this is really an issue that we must properly address.

    We have a product where we are using 3 cameras, they are connected with cables of about 50cm. They are commecial USB cables.

    Sometimes the system will not recognize a camera. The LOCK pin never comes up, or it goes low after some time. But a restart of the software (not the pc!!) often resolve the issue. If a board stops to be recognized and a restart does not brign it up, removing and reconnecting the cable resolve the issue (as in this case).

    What I really need is some debugging tool to understart what is happening when the DES senses something on the other end of the cable, but it will never LOCK properly. We tried using the BLIST test but it will pass. We even tried to overclock the link to 70MHz to see if it has some margin of operation, and it pass successfully. But then, out of nowhere, sometimes the link does not lock and we are stuck with an unresponsive camera.

    We checked the power rails and they seems fine (we are using linear regulators). We do a power cicle every time we establish the link. Register 0x27 is programmed with value 0xE0.

    Any ideas?

    Thank you very much

  • 0 in reply to Ilario Gottardello
    TI__Guru** 107460 points

    Hi Ilario,

    what is the used input clock on your system?

    Have you tried any different cable?

    May be your environment is noisy sometime?

  • 0 in reply to Hamzeh Jaradat
    Prodigy 60 points

    Hello Hamzeh,

    we have two cameras ad 46MHz and one at 50MHz. The cable is not the problem because using a different one may work for some time and then suddenly stops. Exchanging cable between two cameras may resolve, exchanging cameras on the same device may resolve. Is really puzzling us. It may work for months, and then one day it doesn't come up. The device passes the EMI tests for medical devices so it should be quite silent...

    Are there debugging / undocumented registers we may use to have a clue about what's happening?

    Ilario

  • 0 in reply to Ilario Gottardello
    TI__Guru** 107460 points

    Hello Ilario,

    Unfortunately, I do not have any undocumented register which could help you.

  • 0 in reply to Hamzeh Jaradat
    Prodigy 60 points

    Ok, any other idea? Some sequence of register values? Something critical to check?

    I have right here a device with a camera that stopped working yesterday, same case: DES senses something but it's not able to establish a link.

    Ilario

  • 0 in reply to Ilario Gottardello
    Prodigy 60 points

    I've done some tests and there is a weird behaviour happening.

    I'm polling the registers quickly (about three times per second), the deserializer is configured at default register values with 0x27 = 0xE0, and the status register 0x1C gives me the Signal Detect Status bit even if the cable is disconnected. But it goes high or low at no particular order. If I do a Remote Wake-up procedure, on the links that works it goes solid 1, but in the faulty one it continues to go high and low.

    How is it possible that the deserializer detects an active signal even if there is nothing connected? From the schematic I see that the pads DOUT+/DOUT- are connected through 100nF capacitors directly to the USB connector.

  • 0 in reply to Ilario Gottardello
    TI__Guru** 107460 points

    Hello Ilario,

    can you send me a register dump from both devices at the beginning of transmission and one more after you see few error ?

  • 0 in reply to Hamzeh Jaradat
    TI__Guru** 103215 points

    Hello llario,

    Any update here? Is it possible to get register dumps?

    Best Regards,

    Casey 

  • 0 in reply to Casey McCrea
    Prodigy 60 points

    Hello Hamzeh, hello Casey,

    sorry but I was out of office for some time. I don't have a dump of the registers right now but I can anticipate to you that the CRC error counter registers did not signal issues.

    I think we have found something. We looked ad the signal in the serial bus and found that, when the link doesn't come up, there is a signal quite different than when is in power down mode or functioning properly.

    In this chips there is the PDB pin, and on our boards is pull-upped to VDDIO. Threre is not a capacitor to have an RC like is suggested on the datasheet. Connecting a capacitor to delay this pin seems to address the issues. The funny thing is that this doesn't happen on all boards, we have quite a few already sold that does not manifest the issue at all.