TUSB212: More Integration & Question on PU Requirements

for TUSB32x,  you can not prevent back drive, if pullup to different supply other than device supply Vdd. It's better to pullup with VDD.

we have HD3SS3220 with CC controller and USB3 Mux. If trace is long, then you need to consider uSB2 or USB3 redriver.

TUSB542 is USB3 redriver with mux but no cc controller.

Tanks

Brian

Brian,

Thank you.

What constitutes a USB (2.0 & 3.x) long trace, where a re-driver is necessary?

 Could I use the USB VBUS (5V) to source VDD to the TSUB320 with appropriate delay, either at 5 or 3.3V?

 I gather TSUB320 supports either 900mA @5V or 1.5A @5V over the VBUS. But if you need to supply 3A @5V, then you will need a different part?

for USB3 with 5Gbps, max loss for trace length + mux loss + connector loss < 10db, if more than 10db, you need redriver.

For USB2, normally ok with trace lengh unless has long cable .

It's ok to use vbus to source VDD if for UFP. For DFP, you need separate 5V to supply Vbus.

for current mode, you need vbus switch to supply 3A if for DFP. For UFP, it just detect 3A current, so no need different part.

Brian,

Thank you. Let’s look at the back drive issue again. I am operating TUSB320 in UFP & GPIO mode with Port pin tied Low and ADDR pin as NC, so PU to VDD is an option. What would you recommend for back drive protection devices?

I do not have I2C resources & want to use the GPIO mode. I gather at GPIO mode you will need a GPIO pin from processor or controller to interface with TUSB320. Which TUSB320 pin will be available to interface with processor, and how does GPIO mode operate?

for UFP, ID is not needed, so you can leave it open.

INT needs to pull up if you want to update register change information.

OuT1/OUT2 needs to pull up if need to detect current mode. 

if nothing needed, just leave these pins open.

Thanks

Brian

Hi Brian,

Thank you. What about GPIO MODE?

I have a few more question as I make design selections.

TUSB211 (USB2 Re-driver)

I do have one question about RSTN. What does TI offer for a RST control + PWR sense for a 3V ramp to fit TUSB211?

TUSB542 (USB3.X Re-driver)

I was interested in using this part since it is Type C part. However, the air to air gap is too small for manufacturing. The symbol is still being built, but is there equivalent TI part with wider pitch?

TUSB522 (USB3.X Re-driver)

At the moment I am using this part, but it is not a Type C Re-driver. What are the issues if I want to use a type C connector with this part? Does this part work with Type C?

TUSB320 (Type C controller)

I am providing VDD/VCC to this chip and the re-drivers locally, but once the USB connections are made I want to use the VBUS to source power to the rest of the CCA with 5V @900mA/1.5A to be more than sufficient. What are the TI offering to condition 5V, and are there delay issues to consider?

TUSB211 ( suggest to use 212),after you change EQ setting , it only effective after RST.

TUSB542, we don't have other USB redriver mux to replace it so far.

TUSB522, you need mux to switch between TX1/RX1and TX2/RX2 for type-C , so you need TUSB522 + USB3 mux like TMUXHS4212

TUSB320, there are should be lots of options, any Vbus switch (5v, 3A) should work.

Thanks

Brian

Brian,

Thank you. As I am finalizing parts selection, I have a final power related question. I plan to use USB VBUS to deliver power to my card, so the type C controller and Re-drivers VDD/VCC will be sourced from VBUS to 3.3V & 1.8V. Are there any known or potential issues using this method with TI USB Type C devices? Are there any specific TI recommendation to implement VBUS power delivery?

what estimated supply current for your card, CC cotroller like TUSB320 can support 3A/5V, total like 15W. If more than that, you need PD controller for it.

Thanks

Brian

Hi Brian,

5V @ 900mA or worst case 1.5V is all I need. Isn’t TUSB320I also a PD controller?

 So, I can use an USB Type C connector on my card (Receptacle) and use USB VBUS (5V) to bring in the power for my entire Card?

yea, just Vbus should work.

TUSB320I is CC controller, not PD controller.

Hi Brian,

I see the below approach all over TI documentation for USB2.0. Is this a valid approach, where the 2nd D+/D- is routed to USB2 conditioner and mixes with the A side of the Type C connector?