DS92LX1621: DOUT error under Power supply momentary interruption

Hi Ninomiya-san,

Is the customer using these devices in camera mode or display mode? When it is reported that DOUT is "lost", does this mean a loss of lock on the deserializer or no more video?

Do we know what data rate they are running in their system?

Do you have any precedent for this serializer DS92LX1621?

I'm not sure what is asked in this question. Can you clarify?

Before I can answer the other two questions, I will need more information about the customer's system and the whether it is indeed deserializer lock that is lost. If the power supply for the DS92LX1621 is lost for 75ms then I would be suspicious that nothing else in the system was impacted. The DS92LX1621 will use the incoming clock signal to generate the forward channel and if that is impacted it will results in no video and loss of lock.

The DS92LX1621 and DS92LX1622 have registers that give a limited diagnostic understanding. If these registers could be accessed it would be helpful.

Best,

Jack

Hi Jack-san

> camera mode or display mode?

The I2C is configured as a slave by setting the M/S pin to high for both the serializer and deserializer.

> this mean a loss of lock on the deserializer

Yes. DOUT has an offset DC voltage of about 1.2V, and the amplitude is zero. After that, no matter how long I wait, the deserializer does not lock.

>data rate

PCLK is 40 MHz.

The entire system, not just the DS92LX1621, loses power supply for 75ms. After the power is restored, the system is released from reset by the power monitoring IC. The PCLK supplies a 40MHz clock signal to the DS92LX1621.

Best regards,
Customer

Hi Yamazaki-san,

Thank you for the additional information. Is the I2C master attached to the deserializer performing the remote wake up sequence after the system power is restored?

Remote Wake Up Sequence

1. Write 0xC0 to register 0x26 of device 0xC0

2. Write 0x04 to register 0x01 of device 0xC0

3. Write 0x00 to register 0x26 of device 0xC0

Best,

Jack

Hi Jack-san,

The deserializer's I2C master is not sending the remote wake-up sequence.

Is this related to the serializer not outputting?
Best,

Yamazaki

Hi Yamazaki-san,

Not sending the wake-up sequence could potentially be related to the serializer not outputting but I want to ensure I understand the system at a high level so I do not miss any details.

Does the below diagram roughly match your current system in regards to placement of the imager and the MCU? I did not include an SoC or display at the deserializer since it is not relevant for obtaining lock on the deserializer.

The I2C is configured as a slave by setting the M/S pin to high for both the serializer and deserializer.

The M/S pin for the serializer and deserializer cannot match (i.e. be set high for both devices). 

If you are operating in camera mode then the deserializer M/S pin needs to be set HIGH while the serializer M/S pin needs to be set LOW.

Best,

Jack

Hi Jack-san

Actually, our system is configured as shown in the diagram below.

Master SoC sends a data transmission request, and the Slave SoC continuously sends data. Both SoCs operate as I2C masters.

Hi Yamazaki-san,

Thank you for the system diagram and the scope shots. Are you able to read the registers on the LX1621?  

The datasheet specifies that the M/S settings for each SERDES pair must be complementary. Because there is an abrupt power down and power up sequence this could potentially cause a race condition where one device is strapped incorrectly and is expecting a wake up signal.

Are you able to try setting the M/S pin on the LX1622 to LOW?

Best,

Jack

Hi Jack-san

I can read the registers on the LX1621. which register should I read?

I set the M/S pin on the LX1622 to LOW, but situation did not change.

I also tried the remote wake-up that you mentioned earlier, but it didn't improve.

Best,

Yamazaki

Hi Yamazaki-san,

Can you read the following LX1621 registers?

• 0x0 (I2C Device ID)
• 0x1 (Reset)
• 0x3 (Device Config)
• 0x6 (DES ID)
• 0xC (PCLK detect, CRC check, Cable link status detect)

Are you able to try doing a reset of the LX1621 over I2C (Write 0x1 = 0x1)? Also is it possible to measure the incoming PCLK on the LX1621 to confirm that the PCLK is operating as expected?

Best,

Jack

Hi Jack-san

The PCLK supplied to the LX1621 was 40MHz as designed, even when DOUT was not outputting.

I tried resetting the LX1621 over I2C (writing 0x1 = 0x1), but it did not work.

I read the register value.

I2C addresses are set using the CAD pin. The LX1621 is set to 0x59, and the LX1622 is set to 0x61.

I also attach the results of the dump.
slave SoC side.
i2c@raspberrypi:~ $ i2cdump -y 1 0x59 <-LX1621
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: b0 00 20 33 80 40 c0 00 00 01 00 00 04 11 01 03    ?. 3?@?..?..????
10: 03 03 03 00 00 31 80 00 00 00 00 00 00 a0 20 00    ???..1?......? .
20: 0e 1c 29 00 00 00 00 00 00 00 00 00 00 00 00 00    ??).............

i2c@raspberrypi:~ $ i2cdump -y 1 0x61 <-LX1622
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c0 00 00 31 00 00 0f b0 00 00 00 00 00 00 00 00    ?..1..??........
10: 00 00 00 00 00 00 00 00 00 01 ff ff 07 17 07 01    .........?..????
20: 01 01 01 00 00 00 00 00 00 20 00 00 00 08 00 00    ???...... ...?..
30: 00 00 00 a4 fa 00 00 00 00 00 18 60 00 00 00 10    ...??.....?`...?

master SoC side.
LX1621:
i2c@raspberrypi:~ $ i2cdump -y 1 0x59
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: b0 00 20 fb 80 40 c0 00 00 01 00 00 04 11 01 03    ?. ??@?..?..????
10: 03 03 03 00 00 31 80 00 00 00 00 00 00 a0 20 00    ???..1?......? .
20: 0e 1c 29 00 00 00 00 00 00 00 00 00 00 00 00 00    ??).............

LX1622:
i2c@raspberrypi:~ $ i2cdump -y 1 0x61
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c0 00 00 e9 00 00 0f b0 00 00 00 00 00 00 00 00    ?..?..??........
10: 00 00 00 00 00 00 00 00 00 01 00 00 00 17 07 01    .........?...???
20: 01 01 01 00 00 00 00 00 00 20 00 00 00 08 00 00    ???...... ...?..
30: 00 00 00 a4 fa 00 00 00 00 00 18 60 00 00 00 10    ...??.....?`...?


I correct my previous statement about the system diagram. There is a multiplexer DS25MB100 between the LX1621 and LX1622 in the return path.

Hi Yamazaki-san,

From the register dumps I can see that both LX1621 devices are recognizing the incoming PCLK. 

What is the MUX buffer used for in this system? If LOCK is not working for that SER->DES connection, how can we be sure that the MUX buffer is not causing issues?

If the incoming PCLK is not stable that could potentially cause link issues. Doing the following write to the LX1621 will force the device to use the internal 25MHz clock instead of the PCLK for generating the link.

• LX1621 register 0x26 = 0x8

Best,

Jack

Usage of MUX buffer:
The number of slave devices can be one or multiple. MUX buffer is inserted to switch the paths so that the serial communication routes are connected in a daisy chain manner.
It cannot be confirmed that the MUX buffer is not causing issues, but it is certain that the output of the SER is different from normal.

I tried setting LX1621 register 0x26 to 0x8, but there was no change in the SER's DOUT.

So far, the only time I was able to bring about a change in the SER's DOUT was when I briefly grounded the PDB pin of the SER while it was in the non-output state and then returned it to 3.3V.

Hi Yamazaki-san,

In your first response it was stated that cycling PDB did not fix the loss of link. Was there anything different when you cycled PDB this time?

If we are seeing that a PDB cycle is resuming the link this could indicate that the PDB pin is not following the intended sequencing. Is there a RC circuit attached to the PDB pin to ensure that PDB is only asserted once 1.8v and 3.3v is stable?

Best,

Jack

Hi Jack-san

When I said that a PDB cycle does not fix the loss of link, I performed the following operation:
　Send 10 pulses to set PDB to 0V for 1ms at 300ms intervals, starting 5 seconds after power on. 
　After that, I checked the state of DOUT with an oscilloscope.

This usually fixed the loss of link, but it was not always complete.

I confirmed the 1.8V and 3.3V power supplies and the control of the PDB with an oscilloscope. The 1.8V and 3.3V rise simultaneously, and the PDB also rises together with the 3.3V. After a little over 200ms of power stabilization, the PDB drops to 0V for 12us and then returns to 3.3V.

Hi Yamazaki-san,

Is the PDB pin directly fed by the 3.3v rail? It is required to delay PDB assertion until the 1.8v and 3.3v rails have stabilized. It is not recommended to tie the PDB pin to the VDDIO rail.

Hiroaki Yamazaki said:

After a little over 200ms of power stabilization, the PDB drops to 0V for 12us and then returns to 3.3V.

Is there a reason for this 12µs drop? Typical PDB low time recommendation is 2ms.

Best,

Jack

Hi Jack-san,

The PDB pin is connected to the FPGA output pin, not at 3.3V rail. It seems that when the logic of the FPGA output is not determined, it outputs around 3V. Pulling down the PDB with a 1k resistor might have solved the issue.

Thank you