DS90UB935-Q1: I2C return all 0xFF

Hello Ryan,

As a starting point and sanity check, could you help check or provide the following information in your customer system?

1) Would you be able to provide the schematic, so that I can check the resistors and voltages applied to the IDX and I2C_SCL & I2C_SDA pins in the 962 and 935 devices? Since this is a public forum, you may also email them to me if it is not possible to share the schematics here.

     a) For a sanity check, I'd like to confirm that the schematics match what is described in the datasheets. I also want to make sure the I2C HIGH/LOW thresholds are set appropriately.

2) Is LOCK ever lost during the test?

     a) Check register 0x4D[4] and register 0x4D[0] in the UB962 during the test.

3) Has the "Power-Up Sequence" for both devices been followed and meet the minimum delay before I2C commands are sent?

     a) See each device's datasheet for more details on timing.

4) Is the remote I2C commands from (Master->Slave) the only issue? Are you able to successfully send local I2C commands directly to the 935 and 962. Or send other remote I2C commands (Master->962->935) or (Master->935->962)?

Best,

Justin Phan

Justin,

1) I will try to get schematic and feedback to you

2) I just request customer to dump all registers to check 0x4D register. But it should be OK because all video traffic are OK.

3) Yes, we checked power up sequence carefully.

4) Yes, only from master to slave. I2C access master > 962, master >962>935 are all OK. 

BTW, I2C access is 10Kbps. 

And we got some I2C signal capture with scope when problem is duplicated as below: (Green is SDA, Red is SCL)

Bad I2C capture at 935 + slave side. Master still can get right data through this I2C access. But After below I2C access, UB962 keep returning 0xFF to master read and UB935 doesn't issue any I2C read to slave any more.

The strange thing for this capture are:

1. There are 10 clock. It should be 9 clock.

2. UB935 doesn't issue ACK at rising edge of the 9th clock

3. After the 11th clock rising edge, the clock stuck at high for ever.

Could you comment what might cause this?  I also attached good I2C capture following.

Bad I2C capture at 935 + slave side.

Good I2C capture at 962 + master side

Good I2C capture at 935 + slave side

Hi Ryan,

This might potentially be an addressing issue. When the Master is sending an I2C command to the remote Slave (Master->UB962->UB935->Slave), you would need to first program the SlaveID/SlaveAlias in the UB962. Each Rx Port on the quad hub can be configured to hold up to 8 different SlaveID/SlaveAlias pairs and the Slave Alias needs to unique throughout all Rx Ports. Then you would write to one of the defined Slave Aliases to send the I2C command to the appropriate remote slave device connected to a serializer at one of the Rx Ports. 

Could you confirm the following steps have been performed in the script for the UB962?

1) In register 0x4C, set one of the appropriate RX_WRITE_PORT_x bits to write to Rx port-specific registers.

2) Set register 0x58[6] = 1 (Enable I2C pass through)

3) In registers 0x5D - 0x6C, set the appropriate SlaveID/SlaveAlias pair, where SlaveID is the I2C address of the remote slave and SlaveAlias is a unique address that doesn't conflict with any other address on the I2C bus.

4) Send I2C command to the defined SlaveAlias.

Here is also a link to an App Note that may be helpful for general troubleshooting of the I2C bus, which can referenced:

SCAA106.pdf

Best,

Justin Phan

Justin, 

SCAA106.pdf are really helpful. I will study it.

Sorry for confusion. I maybe didn't make it clear. 

The issue only happen like 1/100 chance. At most case, it is no problem. So the normal procedure like SlaveID/SlaveAlias should be no problem. 

And If master issue address every time to read slave. It is also no problem. The problem only happen when master read a block data which means the master only issue address once. Slave will increase address internally automatically. At 1/100 chance, after the first like 1000+ bytes correct, the following bytes only return 0xFF by UB962. And UB935 won't issue any read to slave for the following bytes. 

You can see Figure 4. of SCAA106.pdf are correct. But customer captured bad I2C signal like above. What might cause this signal?

Thanks

Hi Ryan,

Okay, so the SCL should send 9 pulses (8 pulses for 8 bits and one for ACK/NACK) but the "bad capture" suddenly has an extra 10th pulse, which causes the I2C to lock up and prevents the master from starting new transactions.

The unexpected extra pulse is a sign that maybe on the (935 + slave) side, there is another component on the I2C bus that is pulling LOW too, and thus creating an unintended extra pulse.

Are there any other I2C devices connected to the I2C bus on the (935 + slave) side? Are there any connected I2C buffers or multiplexers on the (935 + slave) side that could possibly be generating some type of extra glitch pulse?

If so, I would recommend trying a test setup with commands sent from (Master->962->935->Slave). But on the (935 + slave) side, disconnect everything from the I2C bus except the one slave device. And then see if the lock-up issue still occurs. This would narrow down if some other components on the I2C bus are causing this issue.

Attached is another App Note describing the I2C bus:

SLVA704.pdf

Best,

Justin Phan