TUSB320: Require Architecture Support - TUSB2036 + TPS2042D + TUSB320

Hello, 

We are OOO today for the U.S holiday. Expect a response by EOD tomorrow.

Thanks,

Ryan

Hello,

How exactly is your hub designed? Are you using type-C connectors for both the upstream and downstream ports? Schematics or a block diagram could help illustrate.

If you are using type-C ports for the downstream connectors then yes, you will need to use a CC controller like the TUSB320 or the TUSB321.

CC Controllers are used with type-C ports to determine the orientation of the port, as well as the control when VBUS is sent through the type-C connector. Type-C connectors are not meant to supply VBUS at all times and typically use an external controller, like the TUSB320 for example, to determine when to enable VBUS.

You could try using a TUSB320EVM to see if that helps improve your performance at all.

Thanks,

Ryan

Hi Ryan, 

     Apologies for the delayed response. I have made a crude block diagram for your reference. This is my current design. 

    1. I have used only one Type - C connector towards charger side. ( DP, DM and CC lines communicating with charger for 5V/3A through AP33771 PD controller for Vbus supply to my board ) 

   2. The Vbus is fed to LDO ( 3V3 for TUSB2036 ) and Load switch 1 & 2 ( Host tablet , BLE speaker, Microphone )

   3. The USB Hub upstream is given to Type A connector ( Type A to C cablet to Host tablet ) 

   4. The hub downstream is given to three Type A Connectors (  Type A to C cablets to BLE speaker, Raspberry and Microphone )

Note : I have given Vbus to Tablet through Loadswitch 2 ( hoping that, the tablet will be able to enter OTG and charge mode ). But, the tablet is entering only charge mode, but not enumerating the downstream ports. 

All I need, is for tablet to charge and act as host enumerating downstream devices so that I can do data transfer of my downstream devices. Please let me know if adding TUSB320 works in the upstream for role configuration as host + power sink.   

Hi Aslesh,

If there is a PD controller being used, then the PD controller should be able to perform all the same functionality that a CC controller would perform. It looks like this PD controller specifically only works for UFP applications, so I would expect it to work. 

For the upstream at the Type-C port, so it's connecting to a tablet with a type-A to type-C cable correct? Or are you using the type-C purely for power, and you want to use one of the type-A ports to connect to the host tablet? If the type-C is being used for only charging and no data communication, I don't believe there should be any issue coming from there. It is likely a difference in performance between Linux/Windows and Android. Have you tested with any other devices, I.E IPhones or anything similar?

Does the tablet have a type-A port, or is it using a C to A adapter? For C to A, flipping the cable has no effect correct? Do any different cables or connectors have any effect?

Thanks,

Ryan

Hi Ryan, 

Q) For the upstream at the Type-C port, so it's connecting to a tablet with a type-A to type-C cable correct?

A) No. The Type C port is purely for charger adapter to get 5V, 3A. The communication is purely between Charger and PD controller. This circuit is not upstream, nowhere connected to the hub. This is used only for getting external power supply to the board. 

Q) Or are you using the type-C purely for power, and you want to use one of the type-A ports to connect to the host tablet?

A) Yes, Type -C purely for power. I had planned to use Type A port to connect to the host tablet upstream. 

Q) It is likely a difference in performance between Linux/Windows and Android. Have you tested with any other devices, I.E IPhones or anything similar? 

A) This is what I have observed so far.  

    a. Linux OS host system when connected with my board detects the hub, enumerates the downstream devices and works perfectly.  

    b. Windows OS host system when connected with my board detects the hub, displays a power surge warning on the windows driver notification. Further, the warning box disappears followed by hub detection, enumerates the downstream devices and works perfectly. ( I do not know the reason for power surge error, as the loads are BLE speaker and Microphone, which together consumes hardly 1000 mA ) 

    c. Android devices ( phone / tablet ) simply charges through the 5V output from load switch ( default enable by pull down resistor ). The device notification simply shows charging. No hub / downstream device detection happened here. 

    d. In TUSB2036 datasheet, the upstream device Vcc is not connected to Vbus. ( I have connected the Vcc through load switch hoping, it will charge after enumeration ). 

    e. In TPS2071EVM, the upstream device is not connected to Vbus, So, the tablet is only in host mode giving output voltage OR in host mode tablet is allowing downstream devices to draw power from external supply. But, I haven't seen host tablet act as host + sink in the upstream port. This is working on all OS systems. ( But, I want the upstream tablet to charge as well ) 

Q) Does the tablet have a type-A port, or is it using a C to A adapter?

A) Tablet is type C connector. I have given Type A connector in my board. I am using Type A to Type C cable for connection. I am expecting tablet to perform host + sink operation. Type A connector has DP0,DM0, Vcc and GND lines. I did not connect CC lines ( I am unclear if CC lines are mandatory here to tell the tablet for host + sink operation )   

Q) For C to A, flipping the cable has no effect correct? Do any different cables or connectors have any effect?

A)

       a. Flipping cable has no effect.

       b. I have tried to use OTG adapter cables in different variations. I wanted to see if leaving CC lines unconnected is the problem for enumeration failure. But, OTG connectors also did not help. 

I would like your help, to modify the current architecture, so that the upstream host tablet can act as host + sink simultaneously.   

Hi Aslesh,

Aslesh Kumar said:

Q) For the upstream at the Type-C port, so it's connecting to a tablet with a type-A to type-C cable correct?

A) No. The Type C port is purely for charger adapter to get 5V, 3A. The communication is purely between Charger and PD controller. This circuit is not upstream, nowhere connected to the hub. This is used only for getting external power supply to the board. 

Q) Or are you using the type-C purely for power, and you want to use one of the type-A ports to connect to the host tablet?

A) Yes, Type -C purely for power. I had planned to use Type A port to connect to the host tablet upstream. 

Got it, I wanted to confirm. If the type-C port is only being used for power then the CC pins of that connector should only need to connect to the PD controller. Routing the DP/DM and CC pins of that connector to the PD controller should be enough if just being used for power.

Aslesh Kumar said:

    b. Windows OS host system when connected with my board detects the hub, displays a power surge warning on the windows driver notification. Further, the warning box disappears followed by hub detection, enumerates the downstream devices and works perfectly. ( I do not know the reason for power surge error, as the loads are BLE speaker and Microphone, which together consumes hardly 1000 mA ) 

Could you post your schematic for the TUSB2036 and the power surrounding it, I.E how VBUS is provided and how the hub is powered? It may be good to review those just to make sure they look as expected.

Aslesh Kumar said:

    e. In TPS2071EVM, the upstream device is not connected to Vbus, So, the tablet is only in host mode giving output voltage OR in host mode tablet is allowing downstream devices to draw power from external supply. But, I haven't seen host tablet act as host + sink in the upstream port. This is working on all OS systems. ( But, I want the upstream tablet to charge as well ) 

It sounds like you're looking for the upstream type-A port to act as an OTG port, with the tablet acting as a Power Sink and a Data Source. Unfortunately, the TUSB2036 does not natively support OTG, so it will not be able to support this functionality. The Linux/Windows systems are able to support this because they do not require VBUS to be provided to them for a connection and only require a data connection. if you are providing VBUS to the hubs upstream port, that may be why Windows is throwing the power-surge error as it is being provided 5V while the Windows system is already providing 5V.

If you want the upstream port of the TUSB2036 to act as a Power Source and a Data Sink while still using the TUSB2036, you will need to switch the upstream port to a type-C port and use a different PD controller that allows for role swapping, as well as keeping DP/DM routed between the hub and the connector. Our team does not cover PD controllers, however other teams at TI do support our PD controllers: https://www.ti.com/product-category/interface/usb-ics/usb-type-power-delivery-ics/products.html . My best recommendation would be to look through this list of PD controllers, and create a new E2E under the device name your interested in if you need guidance with configuration.

Thanks,

Ryan

Hi Ryan, 

    You are right. I would like to use TUSB2036 as I do not want to change the current design too much. I would like to know if the PD controller between the USB hub and USB type C connector will resolve the issue for sure. I have a few product deliveries planned for this and it must be resolved in this iteration.

I would like to control PWRON pins of the TUSB2036 to be able to shutdown based on a software command. Can you let me know if this is achievable ? 

Attaching the schematic for your reference for confirmation.  

Ryan, 

        I have gone through the PD controllers. Looks like all of them are I2C configurable.

1. Can this OTG and power sink configuration be done by simply pulling down Rd resistors with 5.1 kOhm ?? Please let me know

2. I do not have MCU or EEPROM in my design. Can you suggest any hardware configuration based PD controllers that can suit my application ?