• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 34 subscribers
  • Views 178 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.

TUSB1004: TUSB1004 Default State in I2C Mode - Disabled?

Steve
Prodigy 130 points

Part Number: TUSB1004

Hi, 

We have been looking at using TUSB1004 for application with two separate USB 3.2 Gen 2 interfaces from same device (can act as either host or peripheral). 

We were expecting TUSB1004 in I2C mode would come up in default state such that it's enabled with certain default EQ settings, and we could adjust various Equalization etc. settings later on if need be for given external cabling setup. 

However we have noticed the following in the register map: 

  • CTLSEL bits of General_1 register default to 0 which is 'Disabled'image.png
  • USB_MODE bit of USB_MODE register is set to 0 which indicates both USB lanes disabledimage.png

Can TI clarify if the TUSB1004 in I2C mode will be totally disabled at startup such that no USB device detection/enumeration is possible until the above two registers are enabled by I2C writes, or can it detect/enumerate USB devices prior to I2C writes?

If so that would not work well for our application, and I'd ask

  • Does TI have another recommended redriver for QTY:2 USB 3.2 Gen 2 interfaces that is enabled at startup in I2C mode?
  • Is anything other than the lack of ability to put TUSB1004 into compliance mode lost when using GPIO strap mode rather than I2C mode? Our assumption is the TUSB1004 would be enabled by default in GPIO strap mode.

Thanks!

  • 0
    TI__Guru 55216 points

    Hi,

    In I2C mode, the TUSB1004 samples the configuration pins upon startup. This is the default state of the part. Afterwards, I2C writes can override this default state.

  • 0 in reply to Vishesh Pithadiya
    Prodigy 130 points

    Thank you Vishesh. 

    I see none of the configuration pins directly impact the state of USB_MODE (bit 0 of register offset 0xD) or the state of CTLSEL (bits 1-0 of register offset 0xA).

    Thus the TUSB1004 default state in I2C mode has both these bits in their reset state of '0' and both USB lanes are disabled until I2C writes override the default state of those registers like I see is stated is section 7.3.4 below. 

    Does TI have any recommended USB redrivers where the default state in I2C mode is to have these bits enabled such that the USB lanes are enabled by default without needing to be overridden by I2C writes?

  • 0 in reply to Steve
    TI__Guru 55216 points

    Hi,

    Steve said:
    Can TI clarify if the TUSB1004 in I2C mode will be totally disabled at startup such that no USB device detection/enumeration is possible until the above two registers are enabled by I2C writes, or can it detect/enumerate USB devices prior to I2C writes?

    The TUSB1004 only affects the USB3.x SSTX/ SSRX lanes. The USB2.0 Dp/ Dm lanes will be unaffected. This means the USB port will always be able to enumerate as a USB2 port regardless of the status of the TUSB1004. 

    Steve said:

    Thus the TUSB1004 default state in I2C mode has both these bits in their reset state of '0' and both USB lanes are disabled until I2C writes override the default state of those registers like I see is stated is section 7.3.4 below. 

    Does TI have any recommended USB redrivers where the default state in I2C mode is to have these bits enabled such that the USB lanes are enabled by default without needing to be overridden by I2C writes?

    Unfortunately, we do not have any single chip redriver solutions for 2x independent USB 3.2 10Gbps Type-A ports. 

    One workaround for you concern could be:

    1) Test TUSB1004 in GPIO mode

    2) Change TUSB1004 into I2C mode, and tune the port for the pre-channel and post-channel losses in the system

    3) Adjust to the desired settings in GPIO mode

    4) Chnage TUSB1004 back to GPIO mode tuned for the system

    Another solution is to enable and use the part in I2C mode. Is there a reason the part was design in I2C mode, but will not be configured in I2C mode on startup?

  • 0 in reply to Vishesh Pithadiya
    Prodigy 130 points

    Thanks Vishesh. 

    For normal operation, configuring device via I2C on startup works fine. 

    However we have scenario where we are in programming/maintenance mode in which case the controller would not have ability to drive the I2C bus but we would still need the USB port to work for maintenance/programming. It's this case that it's problematic if the redriver does not enable by default. 

    We were expecting to use USB3 speeds in in this scenario, but USB2 in this scenario may be good enough for us. 

    As far as USB2 always working regardless of redriver state, our team is concerned that the controller may get stuck trying to talk at USB3 speeds if it sees the TUSB1004 redriver termination without the driver being enabled. We are thinking we may need to have SLP_S0# pin default low to ensure this doesn't happen, do you think that's correct or SLP_S0# state does not matter for USB2 enumeration when USB3 enumeration is not possible with TUSB1004 disabled by default?

  • +1 in reply to Steve
    TI__Guru 55216 points

    Hi,

    A USB 3.x host/ device will always try to enumerate as a USB3.x port before going back to to USB2.0. The TUSB1004 has a built in RX detect circuity designed to be transparent between the host and device. This means that if the TUSB1004 is not enabled the terminations for the part will be high-z. This means USB3.x enumeration will not be possible, and the host/ device will default to USB2.0.

    There is no need to adjust SLP_S0# here.

  • 0 in reply to Vishesh Pithadiya
    Prodigy 130 points

    Thank you Vishesh. 

  • 0 in reply to Steve
    TI__Guru 55216 points

    No problem!