This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TUSB321: TUSB321 not detecting cable inversion

Part Number: TUSB321
Other Parts Discussed in Thread: TUSB542

Hi !

I am using TUSB321 along with TUSB542. 

TUSB321 is used to detect cable inversion and appropriately switch the TUSB542 mux.

I am observing some instability in cable inversion detection. This is not consistently working. This is used in UFP mode, where port pin is pulled down.

Using 909K pull on VBUS_DET. The datasheet says there is a 95K pull down on the pin. If we use 909K, the voltage at VBUS_DET settles around 0.4V . This conflicts with the datasheet where the VBUS_DET threshold is 2.95 to 3.8V.

If I put 47K instead of 909K, the voltage settles around 3.2V. Even after changing to 47K, the CC logic still fails to detect.

Did anyone see this issue or comment on what could be wrong.

Regards

Abdu Samad

  • Hello Abdusaman,

    The 909K resistor is in order to consider up to 20V VBUS, however working with type-C standar conditions there should be no issues with the 95K resistor since the first VBUS on a DFP device must be 5V, unless there is a PD transaction to increase VBUS, and since the TUSB321 has no PD support, this condition is not likely to happen.

    Regards,
    Diego.
  • Hi Diego

    Thanks for replying.

    Please note that we are using TUSB321 in UFP mode.

    According to the data sheet, there is an internal pull down resistor of 95K on VBUS_DET.

    So according to your email, we should make sure we have the correct VBUS_THRESHOLD on VBUS_DET which is only possible with a lesser resistor value ?

    The data-sheet recommends to put a pull up resistor of 900K resistor. It does not mention about the voltage. Could you correct this point in the data sheet ?

    Coming to the actual issue here where TUSB321 does not detect cable reversal with the CC1 and CC2 signals. Does it have any relation to VBUS_DET ? 

    What could be wrong in the design ? Even after changing the VBUS_THRESHOLD voltage (at VBUS_DET) to 3.2V, we still have issues.

    I am attaching the TUSB321 schematic design.

    Regards

    Abdu Samad

  • Did some more investigation last week on the CC signals.
    We are using a Type A to Type C cable in the product.

    1. We probed one of the CC1 signals and VBUS together. The DIR output works properly when the CC1 signal changes before 200ms after VBUS is stable. Whenever it is more that around 200ms, DIR pin does not work.

    2. Is this because of the bouncing of CCs during inseration of the cable to the connector ? I see in the datasheet that deboucning time for CC is 133ms.

    3. We dont see this issue when the cable is plugged from the Type A side (host side).

    4. Also please let us know the correct setting for VBUS_DET.


    Regards
    Abdu Samad
  • Hello Abdu,

    First of all I would like to lcarify VBUS threshold specification you mendioned (2.95V - 3.80V). It is related to VBUS itself and not VBUS_DET voltage. This means that the VBUS_DET pin is capable to detect a voltage as low as 0.295V, so there is no issue when VBUS is 5V and you use the recommended resistor 909KOhms.

    From the original post I understand that you have issues only when the Type-C cable is flipped, but the detection is fine whn the cable is not flipped. THis means that the VBUS detection is fine, and the problem may be related to the CC detection on the DFP side (per Type-C specification the DFP device shall activate VBUS after detecting a valid Rd in any of the CC lines). Please let me know if my understanding is correct.

    -----
    Now my feedback regarding your last post:

    1.-Please provide a detailed test procedure, I've been runnin manual test where VBUS is ON after 2 seconds the CC pin is connected to a Rp termination without issues.

    2.- The bouncing is the minimum wait time for a valid connection.

    3.- The issue is not pressent because the Type-A connector has VBUS always ON, this will force the VBUS detection on the TUSB321.

    -----

    I recommend to verify the conductivity between the TUSB321 CC pins & the Type-C connector, as well as the cables used for testing.

    Besrt regards,
    Diego.
  • Hi Diego

    Thanks for replying

    1. So VBUS_DET can be pulled up to 900K. Thanks for the confirmation.

    2. The detailed test setup  is as follows

    a) The cable used is a Type A to Type C cable with 56K ohm pull up resistor in the cable for CC lines

    b) I get a 0.4V when CC line is connected to the pull up resistor when the cable is inserted.

    c) TUSB321 is used along with TUSB542 USB 3.0 mux chip. The DIR output of TUSB321 drives the TUSB542 select line.

    d) As the logic is inverted for TUSB321 and TUSB542, CC1 on the connector is connected to CC2 on the chip and vice versa.

    e) TUSB321 is configured for a UFP.

    3) Test procedure

    CASE A:-

    a) When the cable is inserted in one direction(i will call it DIRECTION A) , DIR goes low when one of the CCs goes high. In other direction (DIRECTION B)  of the insertion, DIR is high.

    b) For TUSB321, VDD is connected to VBUS. Also VBUS_DET is pulled up to VBUS by 909K.

    c) When cable is inserted in Direction A, VBUS and GND gets connected first in the connector and then CCs and other signals.

    d) I probed VBUS and CC signal. VBUS comes first and then CC1 goes high (in case of DIRECTION A)

    e) When the CC is delayed (say) more than 200ms, DIR signal remains high and never goes low.

    f)  When the CC comes up below 200ms time, DIR signal goes low and works fine.

    CASE B:-

    a) When the cable is inserted in the Type A side (host side), CC comes immediately after VBUS and this always works. As you suggested this is because

    4) As per your reply, the DFP shall activate VBUS only after detecting valid Rd on the CC line. But it looks like that VBUS is always available when connected.

    5) The wait time according to  USB Type C standard is 200ms maximum before it is attached.

    Attached is the snapshot from the specificaiton

  • Hi Abdusamad,


         My bad, I misunderstood the connection sequence, I was talking about  CC pin detection first and then VBUS, but not VBUS, then CC pins detection. The first one should be the right order.

    Regards,

    Diego.