TUSB320LAI: TUSB320LAIRWBR CC Communication & USB_VBUS Drop

Part Number: TUSB320LAI
Other Parts Discussed in Thread: TUSB320

TUSB320LAI_CC_Communication_and_VBUS_drop.pptx

We have designed a product using the TUSB320LAIRWBR and would appreciate your help with a connection issue.

Configuration (see attached schematic):
- Port mode: UFP only. The PORT pin is pulled low to GND through a 4.7 kOhm resistor.
- Control mode: I2C. The ADDR pin is tied to GND (I2C address 0x47), and EN_N is tied to GND.
- Power topology: bus-powered. The connector VBUS goes through a current-limit IC to a 5.0 V system rail, and this rail supplies the TUSB320 VDD.
- VBUS_DET: connected to the same 5.0 V system rail through 900 kOhm total (470 kOhm plus 430 kOhm in series). In other words, VBUS_DET is behind the current-limit IC and is not connected directly to the connector VBUS.

Symptom (see attached waveforms):
- When the board is connected to a laptop with a C-to-C cable, the laptop initially applies VBUS (about 5.1 V), but VBUS then drops to about 0.3 V for about 235 ms and then recovers. This cycle repeats every few seconds, so our SoC cannot complete booting.
- CC2 sits at about 1.6 V DC and shows short bursts of toggling roughly every 150 ms.
- CC1 remains near 0 V.
- Overall, the CC behavior does not look like what we would expect from a UFP-only configuration.

Questions:
1. Could you review the attached schematic and waveforms and advise what may be causing the repeated VBUS drops?
2. Is our configuration (UFP-only, I2C mode, bus-powered, VBUS_DET connected behind the current-limit IC) acceptable, or should VBUS_DET be connected directly to the connector VBUS?
3. Are there any register settings or hardware changes you would recommend for a bus-powered, sink-only application?

Thank you in advance for your support.

Best regards,

  • Hello,

    Looking at the schematic, I see you're using a current limiter for VBUS. Just to confirm, what current are you trying to receive from VBUS, 900mA, 1.5A, or 3A?

    2. Is our configuration (UFP-only, I2C mode, bus-powered, VBUS_DET connected behind the current-limit IC) acceptable, or should VBUS_DET be connected directly to the connector VBUS?

    I recommend connecting VBUS_DET directly to VBUS rather than the limiter. VBUS_DET is crucial for determining when a UFP connection is made.

    If I2C is being used, it would be good to read back registers 0x08 and 0x09 and see what these return. This should tell us the status of the controller.

    - CC2 sits at about 1.6 V DC and shows short bursts of toggling roughly every 150 ms.

    If connecting to a laptop, this is like signaling from a PD controller on the laptop. For a CC controller, this toggling should have no effect on the connection being made.

    If possible, can we monitor this dip in USB_VBUS in relation to the CC1 and CC2 pins, to see if this drop is correlated with activity on the CC lanes?

    1. Could you review the attached schematic and waveforms and advise what may be causing the repeated VBUS drops?

    VBUS dropping should be in relation to the CC connection failing. VBUS should not be supplied by a type-C port if there is no active type-C connection. If there is an active type-C connection, only then will VBUS be attached.

    If DFP or DRP mode are not being used, the ID pin can be left floating.

    I do see the CC pins go through an ESD diode. We typically recommend against this, as they can hamper CC communication. It may be worth removing these diodes and seeing what effect it has.

    3. Are there any register settings or hardware changes you would recommend for a bus-powered, sink-only application?

    You can ensure UFP mode is set by using register 0x0A. Otherwise, please ensure the current advertisement is less than 1.7A per the current limiter being used. Register 0x09 can indicate whether a connection is made or not.

    Flipping the type-C cable has no effect, correct? You see the same performance on CC1?

    Thanks,

    Ryan

  • Thank you, Ryan.
    I'v measured bunch of things you explain so that found out the root cause finally(Master IC write 0X0A / Disable_Term = 1 by I2C)

    Thx a lot