DS92LX1621: cable disconnected but LINK DETECT BIT=1

Hi Luca,

Please read it twice to see if the same result is observed.

Are you experiencing loss of link while the cable is connected as well?  To test, please poll the register to see if there is a change of state while connected.

Sincerely,
Bryan Kahler

Hi Bryan,

my program already polls the register one time each second. If I disconnect the cable I would read LINK_BIT=0, instead 7 times of 10 I read the bit at 1 and the remaining ones at 0.

If I connect the cable I read always 1. But when there isn't a connection this bit is not a sure information for the link.

Is this true? Do you find the same behaviour?

thank you

Luca

Hi Luca,

Please confirm if I'm understanding your procedure:

1) Register is polled at 1s intervals

2) Cable is disconnected from device

3) First reading after disconnection may sometimes be a 1, other times a 0

4) Second reading and subsequent readings are 0.

Sincerely,
Bryan Kahler

Hi Brian,

my procedure is this:

1) Register is polled at 1s intervals (LINK bit=1)

2) Cable is disconnected from device

3) I read the register 1 time each second and the statistics for the LINK bit is 8 times to 1 and 2 times to 0

I must consider a different procedure for read LINK's bit status?

thanks

Luca

Hi Luca,

Your test procedure appears sound.  Still looking into this, please expect an update tomorrow.

Sincerely,
Bryan Kahler

Hi Bryan,

I think this is an important consideration that you must report on the product datasheet.

Your consideration dosn't resolve my problem, beacuse I'm working in DISPLAY-MODE, so if the cable is disconnected the SER's registers  regarding the status of the link ( 0xA,0xB,0xC) are not usable, the only way to detect the disconnection is to poll the DESERIALIZER and test an I2C error. is this true?

During the normal functionality these status register of SERIALIZE ( 0xA,0xB,0xC) are a copy of DES' register ( 0x1A,0x1B,0x1C)?

In my application, if I frequently poll the DESERIALIZE (around twenty I2C communications each second), sometimes happens that the communication fail permanently (and also the stream of 16 bit is wrong), the only way to recover the DESERIALIZER is the power cycle.  There are any setting to do for i2C communication? or any other consideration for a stronger link connection?

My PCLK works at 32MHz.

thanks

Luca

Hi Luca,

Thank you for the clarification and additional information.

The link detection feature is sensitive to noise upon cable disconnection.  Since you're working in display mode and not camera mode, the suggestion of reading 0x1c[0] is obviated as a workaround unless just polling for a response.

Another option would be to read the CRC Check in 0xC[1] to see if there is an error during communication with the Deserializer.  This should not add additional strain to the interface as the link detect bit also requires polling at some set interval and this bit would be polled in its stead.

For a stronger link connection, the recommendation would be to ensure that the jitter and other channel specifications given in the datasheet are met by the design.

If any issues remain, please let me know.

Sincerely,
Bryan Kahler

Hi Brian,

thank you for the answer now is clear that to understand the link I have to check the status on deserializer part.

There is an other issue:

"In my application, if I frequently poll the DESERIALIZER (around twenty I2C communications each second), sometimes happens that the communication fail permanently (and also the stream of 16 bit is wrong), the only way to recover the DESERIALIZER is the power cycle.  There are any setting to do for i2C communication?"

Do you think this is due to the I2c frequency (10KHz)? there is something to set for this?  Or it is useful to reduce the number of communication?

thank you

Luca Turrini

Hi Luca,

Since you are running in display mode, please ensure that after bring up that registers 0x08~0x17 on the deserializer are reset to 0x00.

The i2c bus rate of 10 kHz may very well be the culprit here:

The I2C bus rate should also be set in register 0x05.  The ratio is determined by fSCL / register value (in decimal).

The default setting is 0x40 which results in an i2c bus rate of ~100 kHz SCL where fSCL = 6.25 MHz.

Values below 0x32 are not supported and a maximum theoretical value that will fit in the bit space is 0xFF.  With fSCL = 6.25 MHz and value of 0xFF, the i2c bus rate would be ~25 kHz SCL.

Sincerely,
Bryan Kahler

Hi Brian,

I have setted the frequency of I2C to 100KHz (the default), but I have again some strange errors:

* when I disconnetc the cable the CRC counter on SER sometimes is 0 and other times is different.

*The CRC flag of SER (0xC bit 1),after a cable disconnection, sometimes is permanently at 1, also when the cable is plugged and the connection in ON. After this the I2C link with DES is lost, the only way to restablish it is reset the SER ( register 0x01)

My connection is a DISPLAY MODE, like you can see in the design below.

I hope it could be a wrong setting, could you suggest me the right sequence of the configuation of SER & DES, and what is useful read  via I2C to monitoring the link during normal communication and not to read instead?

Thank you in advance

Luca Turrini

display mode 1621.pdf

Hi Bryan,

Now my i2c bus is running to 100KHz (the default), but I have again some strange behavior:

• If I disconnect the cable the CRC errors on SER (register 0x0A) doesn’t increment
• Sometimes the CRC error flag (0x0C bit 1), after a cable disconnection, stuck at 1, also with cable reconnected, and I can’t communicate with DES; the only way to clear it is reinazialize the SER ( register 0x01 bit 1).

I suppose it could be an I2C configuration error.

Which are the maximum number of polling per second to DES, to not risk a fault?

I append my diagram block of ser-des connection, could you send me the right setting for the device SER & DES?

Thank you in advance

Luca

5481.display mode 1621.pdf

Hi Luca,

For the CRC errors, they shouldn't increment with the cable disconnected. 

To determine that the cable is disconnected, please poll the lock and crc registers.  If a loss of lock is seen, poll the lock and crc register again and the value should not increment.  The CRC errors accumulate during active communication, which requires a cable and lock.

During normal communication (cable connected and lock), if there are CRC errors with i2c, the number of CRC errors should increment.

With respect to i2c throughput, the i2c interface should be available for a subsequent transaction after the transaction is complete.  The maximum rate will vary due to possible clock stretching.

Sincerely,
Bryan Kahler