• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 33 subscribers
  • Views 1173 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.

TUSB320 generates fake Attached.SNK state and incorrect plug orientation and current capability

Andy Hewitson
Prodigy 40 points

Other Parts Discussed in Thread: TUSB320, TUSB320EVM

Hi.

Working on a new design with USB-C and TUSB320 to detect attachment, orientation and current capability.

When configured as an upstream facing port (UFP), the TUSB320 assets an attachment state (register 9, bits 7:6 = 10, ATTACHED_STATE=Attached.SNK) upon the detection of VBUS, before CC connects, and therefore reports false plug orientation and current capability.

GND and VBUS pins in a USB-C receptacles are slightly longer so that they mate before the other (signal) pins.  Since USBC connectors offer some resistance to insertion/removal, there is a delay between the connection of VBUS/GND (longer pins) and the connection of CC1/CC2.

The USB-C attached state (Attached.SNK in the case of an UFP) should only be reached by detection of correct levels at the CC1/CC2 pins.  VBUS it not a sufficient condition on its own to detect cable attachment.

In our application the device uses USB-C for high current charging and USB2.0 communication.  So a common use case is connection using a (USB-C spec compliant) USB2.0 A -> USB-C adapter cable.  For USB2.0 support over USB-C a mux is required to route the USB2.0 signals from the top or bottom row of connection on the USB-C receptacle, depending on which way the cable is inserted.

However, the TUSB320 generates an attached event upon connection of VBUS, *before* CC1/CC2 are connected.  ie: The TUSB320 determines cable orientation and current capability based on open circuit CC1/CC2 connections.  ie: wrong.

I strongly inclined to not assume a silicon defect, but I have tested this any number of ways and always come back the the same fundamental problem, that attachment must not be reported without CC connection.  Yes the TUSB320 does this, and consequently produces unreliable data.

Any help or guidance would be very much appreciated.

Yours

Andy

  • 0
    TI__Intellectual 1990 points

    TUSB320 in UFP configuration should only transition to attached.SNK state after the CC + VBUS have been detected.  It follows the connection state diagram of the sink in the Type-C(TM) specification.  The Attached.SNK state is reached after CC detection then VBUS detection + CC debounce time.  What is the CC voltage when you see the device reporting the Attached.SNK state?  Can you also include the scope capture of the CC and VBUS when the issue occurs?  CC voltage above 0.25V would be detected as a cable connect(which would cause transition to AttacheWait.SNK state.

    Please note that the device would stay in the attached.SNK state unless VBUS has been removed(should be below ~0.2V).  It is possible that the VBUS may not have been discharged completely prior to the next connection event which would result in the device reporting the attached.SNK state from the previous connection event.

  • 0 in reply to Yu-Ning Lee
    Prodigy 40 points
    Hi Yoon,

    Thank you for the response and ideas to debug.

    I have not used my 4-channel scope since we move premises and when I connected everything up, two channels are dead. Dammit! So I'm unable to measure that way. No worries, there are other options....

    My target board is very dense and it's almost impossible to reach the signals for debugging. So I made a breakout fixture with two of these (www.saikosystems.com/.../p-81-usb-type-c-female-receptacle-breakout-board.aspx) so that I can easily monitor the signal levels of VBUS, CC1 and CC2. This also allows me to selectively choose which signals to connect.

    My target board is implemented like Fig 4 on page 17 of the datasheet, with PORT tied to ground, EN driven low and ID open circuit. The only difference is that the VBUS_DET pullup is 910k since 900k is an unobtainable value. (Who came up with 900k???)

    I commence my tests with only GND and VBUS connected on the USB breakout fixture. In this setup, CC1 and CC2 (on the TUSB320 side) are open circuit. ie: when I insert the USB plug, *only* GND and VBUS nets are presented.

    Guess what happens when I insert the USB plug? Yep, I get an interrupt and Attached.SNK. This is without any connection on CC1 and CC2. I also measure those signals with a multi-meter and they are hovering around 0V. The TUSB320 is not waiting for CC assertion before asserting a connected state. It is definitely not following the connection state diagram of the sink in the Type-C spec.

    I'm running out of options, so I decide to try something crazy. I configure the device up as a DRP (register 0x0a, MODE_SELECT = 11). When I do this, the device behaves exactly as expected. I can connect VBUS power and nothing happens. I only get Attached.SNK when CC connects. Also I get the correct CABLE_DIR and CURRENT_MODE_DETECT as advertised by the DFP.

    Just in case I'm missing something, I try to initialise the device with a soft reset and configure as an UFP. No joy. Still misbehaves and connects on VBUS only.

    This is not a complicated part. Few pins and opportunities for careless mistakes. I have verified that I don't have any bad connections on the board. Also the fact that the device behaves correctly when configured as a DRP suggests that the part is wired correctly.

    I've ordered a TUSB320EVM board from Digi-Key so that I can attempt to reproduce the issue on that board. Any suggestions in the interim?

    Yours
    Andy