TUSB1142: TUSB1142 not working on device-side

Hi,

1. Yes, you can use the 1142 on the device side of the type-C connection.

2. You may need to change the EQ settings on our device to get SS communication working. If EQ is too low or too high, the signal can be unrecognizable on the host or device end.

• Additionally, if VIO_SEL is floating make sure the I2C voltage is 3.3V

3. Yes, USB1_STATUS is for CTX1/RX1 and USB2_STATUS is for CTX2/RX2

4. Our device needs to see connections on both sides to exit disconnect mode. You need a host and a device connected.

5. I have a few questions to get a better idea of the issue:

• Are you connecting both a host and device when you test the 1142? The 1142 needs to see terminations on the TX pins before it transitions to the polling state.
• How much power does our device draw? In the disconnect state we expect around 1.5mW. If the device is drawing more power, it should be entering active mode

• Do you see any signal passing through the 1142 between the host and device?
• Can you share the schematic of the 1142 and the routing to your USB connector? I'd like to see if there's an issue with the implementation. You can share this here or privately by requesting friendship on E2E and using the direct messaging feature.

Best,

Shane

Hi Shane,

Thanks for your reply and the confirmation that how we want to use this part is correct. I did find a few things that were wrong on our side and have been able to get a SS connection at last. But there are still a few quirks to work through. 

We had the SSRx and SSTx signals swapped. We have a special application with cables on both sides. The device side is a captive cable where orientation is fixed, but the cable still flips the Rx/Tx signals just like a regular cable. Since the TUSB1142 essentially performs the "cable flip" by SSRx being a transmitter and SSTx being a receiver we essentially had a double-flip, which is of course wrong. I simply misread the datasheet. The diagram in section 7.2 helped clear up any confusion.

Although things are working now I was wondering if you could explain a few I2C register bits for me. I have the FLIP bit set, which switches the mux to CRx2 and CTx2 (pins 36/37 and 39/40), but the connection seems to be indicated in USB1_STATUS via bit U0 (0x04) and not in USB2_STATUS as I expected. Are they flipped?

Also, when the SS connection was established, the USB2_STATUS register read 0x41. This is still disconnected state, but bit 6 was now set and the datasheet defines it as RESERVED. Do you know what this bit indicates?

Hi,

I'll need to confirm whether the USB_STATUS registers are flipped or not. I have a question about the behavior to help narrow this down:

• Does the USB2_STATUS or USB1_STATUS U0 bit get set when you keep FLIP at 0 (normal orientation)? Note you may need to flip the type-C cable as well for the connection to go through.

Reserved registers are for TI testing purposes and are not intended for customer use. Unfortunately I cannot share what that bit indicates.

Best,

Shane

Ah, good question. Here are the I2C register results for both cases:

No Flip:

GENERAL_1 : 0x11

USB1_STATUS: 0x44

USB2_STATUS: 0x01

Flipped cable:

GENERAL_1: 0x15

USB1_STATUS: 0x04

USB2_STATUS: 0x41

This doesn't really make sense. The U0 bit is set only in USB1_STATUS while USB2_STATUS always indicates disconnected state. The only real difference is the reserved bit 6 that follows the flip. I do see that the AEQ1_STATUS register has some bits set when the cable is not flipped and when it is flipped then the same bits are set in AEQ2_STATUS, so that follows the orientation. 

By the way, I have the mux working as expected in both orientation, so I can resolve the issue, but I'm really curious about the USBx_STATUS register behavior. It would be really nice if we could use these two registers for debugging purposes to see which one has the active connection.