TUSB320: Require Architecture Support - TUSB2036 + TPS2042D + TUSB320

Part Number: TUSB320
Other Parts Discussed in Thread: TPS2042, TUSB2036, , TUSB321,

Hi, 

   I have designed a USB 2.0 hub with TUSB2036. My upstream device is android, and downstream devices are BLE_speaker, microphone and raspberry-pi. The power supply is from a charger adapter powering the Vbus rail externally through PD controller AP33771C at 5V@3A. For downstream devices, I have used tps2042 load switches. 

Note : For my upstream android, the Vbus is connected to the USB Type A connector with a load switch (default ON state with pull down resistor). I was hoping, the android would allow OTG ( through hub upstream dp and dm) and charge simultaneously through load switch. 

With this configuration, I tested my pcb with linux/windows OS and the hub successfully enumerated. But, tablets/androids failed to detect/enumerate the hub and the downstream devices. My tablet simply charges silently without any notification. I later found that the CC pins are necessary for role detection in type C and I haven't used them in my design, which could be the bug. 

I would like to get support on the final implementaion. I would like to have otg and charge feature for my android upstream ( not necessarily fast charging, 5V fixed at standard current would suffice ). It should charge and act as host simultaneously, the way off the shelf hubs work in the market. 

Can anyone suggest if I can simply add another IC, which can keep UFP device as host and sink and solve my problem ? I found TUSB320 which may help, but I am unsure at the moment.   

  • 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,

    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.

        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.

        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