• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 572 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TUSB8041A: For Jetson Nano

TUSB8043A: Design Verification with Jetson Nano

Jaya surya
Prodigy 60 points

Part Number: TUSB8043A
Other Parts Discussed in Thread: TPS2595

Hi Team,

We are finalizing one hardware design with TUSB8043A and Jetson Nano SOM. We would like to get the same reviewed by TI community, block diagram attached

Requirements: 4 Port USB hub to connect 4 USB cameras and to supply adequate power to cameras (Approx 250mA per camera)

Note: Design to support USB 2 or 3 inline with connected device's capabilities

Design details:

1. SOC_READY (SYS_RST from Jetson Nano) will enable 3V3 DC-DC to supply VDD33 for TUSB8043A after completion of proper SOM Power ON

2. VDD33 will get supplied before VDD11 as 1.1V LDO is powered using 3V3 rail

3. Active Reset scheme for TUSB8043A with a GPIO from the SOM as shown in image is selected inline with power on sequence

4. USB_VBUS is tied to 1.8V GPIO of SOM through voltage divider. Do we need to give an option to connect the same to 3.3V rail through voltage divider as shown in the image with dotted lines ?

5. Downstream power is managed with GANGED MODE since single TPS2595 is used for powering 4 devices together

6. STRAP Pins or MISC Pins

FULLPWRMGMTZ_SS_UP  -- PD
(Battery charging is not mandatory. However over current inputs and GANGED control towards downstream is required)
GANGED_HS_UP        -- PU
PWRCTL_POL            -- PU
AUTOENZ_PD            -- PU
SMBUSZ                -- PD

Note: External PU & PD options are given to all PIN for maximum possibilities during bring-up

7. Current design is to make the HUB configurable through SMBUS hence tied SMBUSz to PD

Please share your advice to make the design better or if it is having any potential pitfalls.

Regards,

Jayasurya

  • 0
    TI__Guru 60870 points

    Hello Jayasurya,

    Notes inline below:

    4. USB_VBUS is tied to 1.8V GPIO of SOM through voltage divider. Do we need to give an option to connect the same to 3.3V rail through voltage divider as shown in the image with dotted lines ?

    [JMMN]  1.8V can be used to drive USB_VBUS as long as the resistor values are adjusted accordingly.  USB_VBUS should only be high when an active host is connected.


    6. STRAP Pins or MISC Pins

    FULLPWRMGMTZ_SS_UP  -- PD
    (Battery charging is not mandatory. However over current inputs and GANGED control towards downstream is required)
    GANGED_HS_UP        -- PU
    PWRCTL_POL            -- PU
    AUTOENZ_PD            -- PU
    SMBUSZ                -- PD

    [JMMN]  The pulldown on SMBUSZ should not be installed - if the hub is in SMBUS mode it will wait until a SMBUS host sets the cfg_active bit before connecting.  If no SMBUS or EEPROM is used SMBUSz should be high.

    Note: External PU & PD options are given to all PIN for maximum possibilities during bring-up

    7. Current design is to make the HUB configurable through SMBUS hence tied SMBUSz to PD

    [JMMN] If the hub is in SMBUS mode, it has to be configured before it will connected.  Do not install the PD if this is only on the board as an option.  Also, we do not recommend connecting SDA/SCL to a system I2C/SMBUS bus if it is not being used since the hub has internal pulldowns on those pins that can affect signaling levels.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 60 points

    Hi JMMN,

    Thank you for the prompt support

    We got your point regarding SMBUS. We will not install PD and SDA/SCL as we plan to have this as an optional feature

    As you mentioned in the initial thread “The TI hubs use generic standard USB hub drivers, no special driver support is required. We have noted that some Linux versions have difficulty with the intermediate USB 3.x power states (U1/U2). If that is a concern here they can be disabled using Register 05h in the hub”. We assume the same is only possible through SMBUS configuration, please correct if this understanding is wrong

    In line with device driver, we plan to manage RESET & USB_VBUS GPIOs from the generic hub driver. Would like to hear your suggestions on this as well.

    Regards,

    Jayasurya

  • 0 in reply to Jaya surya
    TI__Guru 60870 points

    Hello Jayasurya,

    Yes, the intermediate power states can only be disabled using EEPROM or a I2C/SMBUS host.  We have not been able to determine the issue that was reported with some Linux versions with the U1/U2 power states behind the hub since we were not able to duplicate it in our lab.

    RESET and USB_VBUS are inputs to the hub, I'm not clear on how they could be managed by a generic hub driver.  The hub must have a proper reset to function and USB_VBUS must only be high when an active host is connected to the hub.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 60 points

    Hi JMMN,

    Thank you for the support

    We will get in touch with you during bring-up in case if we come across issues related to version incompatibility with Linux

    Understood your points regarding RESET and USB_VBUS, we will have this de-coupled from the driver and make sure the HUB has proper RESET and USB_VBUS

    Regards,
    Jayasurya

  • 0 in reply to Jaya surya
    TI__Guru 60870 points

    Ok, sounds good.