TUSB322I: VCONN support

Michael Eick

Part Number: TUSB322I
Other Parts Discussed in Thread: TUSB322

I am currenty trying TUSB322I with an active cable. I see TUSB322I reporting ATTACHED_STATE = "Attached.SRC" and ACTIVE_CABLE_DETECTION = 1. However, after a short time (~1 ms), I see TUSB322I reporting ATTACHED_STATE= "Not attached".

Here is a log of the I2C communication:

The write to 0x42 0x03 0x04 enables VBUS. The write to 0x42 0x03 0x1C disables VBUS.

Any hints what I should check?

over 7 years ago

0 Luis Omar Moran over 7 years ago

TI__Genius 16150 points

Hi Michael,

If the device is detecting an attachment (Attached.SRC) and then not attached, it seems the sink was removed and VCONN was OFF. According to the state machine of USB Type-C, once the device detects an attachment (Attached.SRC) has two different options:
1. Come back to Unattached.SRC when Sink REmoved and VCONN was Off.
2. Go to UnattachedWait.SRC when the Sink Removed and VCONN was On, then if a discharge is complete and VCONN Off the current state will be Unattached.SRC.

Best Regards,
Luis Omar Moran
High Speed Interface
SWAT Team

0 Malik Barton57 over 7 years ago

TI__Guru 64326 points

Michael,

There could be several things going on with this I2C communication. If TUSB322I is implemented as a UFP but only the active cable is connected but no USB device this could lead to this situation. Also I would look into the I2C_Soft_Reset condition as this may affect the ATTACHED_STATE bit in TUSB322I.

Could you answer the questions below:

Could you give more information about the application?
Is TUSB322I inside of the active cable?
Is this port supposed to act like a UFP, DFP, DRP?
What do the CC lines like during this time?

0 Michael Eick over 7 years ago in reply to Luis Omar Moran

Prodigy 65 points

Hi Luis,

the sink was unchanged all the time.So, the question is actually why theres is a transitition to an unattached state despite the sink is not removed.

I didn't check yet whether VCONN was really supplied by TUSB322i.

Thanks & Regards,
Michael

0 Michael Eick over 7 years ago in reply to Malik Barton57

Prodigy 65 points

The TUSB322I is connected to a receptacle (A). In the test in question the TUSB322I is configured to act as an DFP.
The active cable is a stock C-to-C cable from goobay. It is pluged into the recptacle (A). On the other end it is connected to another recptacle (B) which is configured as sink/UFP. The CC-Logic of the sink simply consits of two resistors.

I will try to get scope pictures of the CC lines.

0 Luis Omar Moran over 7 years ago in reply to Michael Eick

TI__Genius 16150 points

Hi Michael,

Would you mind providing the schematics for your application please?

Thanks,
Luis Omar Moran
High Speed Interface
SWAT Team

0 Malik Barton57 over 7 years ago in reply to Michael Eick

TI__Guru 64326 points

Michael,

Could you post a block diagram of the application and the location of the TUSB322I? Also could you include Vconn in you scope captures?

0 Michael Eick over 7 years ago in reply to Malik Barton57

Prodigy 65 points

It turns out that there was one additional component connected to the CC wires which was not 5V tolerant and thus caused an error when VCONN was activated by the TUSB322.

Yellow = CC, Green = VCONN

Since the device obviously detects an error, I would like to know why VCONN_FAULT was not set in this case.

0 Malik Barton57 over 7 years ago in reply to Michael Eick

TI__Guru 64326 points

Michael,

VCONN_FAULT is changed based on the current seen at the CC pin. 300 mA is the typical threshold for VCONN_FAULT (Section 6.5 Vconn), if the current threshold is not meet then this bit will not be set.

Also is TUSB322I have 5V on VDD during this error? It appears that Vconn, which is sourced from VDD, is only ~2.5V (max) but should be 5V.