Query regarding DDC (I2C) behaviour of TMDS181 device

Hi Simon,

Yes, this is the right forum for TMDS181 support. The TMDS181 should report the NAK to the DDC source and release the sink bus. Are you seeing a different behaviour? Is the SCL being held low?

Thanks,
JMMN

Hello,

I am seeing this sequence of events:

0) Source reads the sink's EDID over DDC (successfully passing through the TMDS181)
1) Source makes a request to the HDCP device (0x74)
2) TMDS181 passes this through to the sink
3) sink NAK's this request (lets SDA float high)
4) TMDS181 returns the NAK to the source
5) Source initiates a second request to the HDCP device (0x74)
6) TMDS181 swallows this transaction (does not pass it through to the DDC sink)
7) TMDS181 holds SCL_SRC low indefinitely

This prevents all further DDC traffic until a power-down (e.g. hot-plug) event. I can provide scope shots next week.

Have a nice weekend!

Simon

Scope shots of DDC HDCP transactions either side of the TI TMDS181 chip, showing the same DDC transactions immediately following the end of the EDID read. Blue (bottom): SCL; Yellow (top): SDA.

A: ddc_snk_hdcp_nak.png - scope capture between the 181 and the FPGA, i.e. DDC response of the HDMI core

B: ddc_src_hdcp_nak.png - scope capture on the HDMI cable, i.e. DDC response of the TMDS 181 chip

Capture A shows the end of the EDID read transaction on the left, followed by a new DDC transaction targeting device ID 0x74, HDCP. This transaction is NAK'd and then the bus is idled, and remains so with no following transactions.

Capture B shows two attempted HDCP transactions, immediately following the end of the EDID read (not shown - to left of capture). The first DDC transaction, on the left, shows an attempt to access device ID 0x74, HDCP; at the end of this transaction the SCK pulse is stretched (by the 181), and then there is a NAK (in the first cycle of the following burst of DDC SCK pulses). In between the two bunches of pulses there is a single pulse of SDA. The second burst of SCK pulses appears to be a read to address zero.

After these transactions the SCL line (blue) is held low forever, blocking the DDC master from performing any further transactions.

LTC:

TI 4B1

AZDS G4

Hi Simon,

Thanks for the traces. Can you confirm where the traces were taken in the system? It looks like it was {Source - plot B - TMDS181 - plot A - Sink} since the TMDS181 could only hold SCL low if it was acting as the I2C slave.

In Plot A, I don't see the NAK for the HDCP address, I only count 8 clock pulses, did it get NAKed later? In Plot B, the TMDS181 appears to be holding SCL low while waiting on the sink response for the access to address 74h. Once this completes, it holds SCL low waiting on the access to address 00h, does this come through on the sink side DDC?

I'm checking on the date code, we did address one issue with DDC NAKs in early silicon.

Regards,
JMMN

Hello,

Plot A was captured from test-points on the board: SCL_SNK blue, SDA_SNK yellow.  This is the sink side of the TMDS181 DDC lines, connected to our HDMI core.  Ignore the transaction on the left, this is the end of the EDID read.  In the transaction of the right there are 9 rising edges on the SCL_SNK line (blue), which is the HDCP transaction targeting device 0x74.  During the 9th rising edge of SCL_SNK (far-right of plot A) the SCL_SDA line is high, indicating a NAK.

Plot B was captured "on the HDMI cable", so shows the DDC response of the TMDS181.  The TMDS181 is acting as the DDC slave: SCL_SRC blue, SDA_SRC yellow.  This shows the TMDS181 holding SCL_SRC low at the end of the transaction - blocking all future transactions.

You ask: "Once this completes, it holds SCL low waiting on the access to address 00h, does this come through on the sink side DDC?"

Plot A shows the final transaction on the sink DDC lines, i.e. the DDC bus remains idle to our HDMI core slave.  Plot B shows an attempt to access the HDCP device on the source side of the TMDS181.  This is NAK'd by the DDC device on the sink (plot A), so the TMDS181 should NAK this on the source side and idle the DDC bus.  Unfortunately it doesn't do this.

Please can you provide an erratum for the "DDC NAK issue addressed in early silicon"?

Please let me know if there is anything else I can capture.

Kind Regards,

Simon

Hi JMNN,

This is a half-year old story and could you now confirm that current silicon revision has the DDC NAK issue fixed?

---

regards,

    Igor

Hi Igor,

As noted in the thread, this issue was present in pre-production samples only. The problem was addressed before the device was released.

Regards,
JMMN

Hi JMMN,

Thank you for the confirmation. The issue was fixed which means a lot of verification tests were carried out and all the data are obtained. Is there other outstanding issues that prevents TI from publishing theory of operation for the Active DDC block in the data sheet (textual description, timing diagrams, worst case values, etc., as usual)? That's the question because three editions of the data sheet document has released so far but the "clock stretching" matter is still not covered.

---
regards,
Igor