• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 1149 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.

TUSB422: Stuck in SNK_DISCOVERY state after hard reset

Devan Lippman
Prodigy 130 points
Part Number: TUSB422

I have a design which is powered from the VBUS rail on initial cable insertion the sink profile is negotiated correctly:

 ________  _________  ____ ___  ___
/_  __/ / / / __/ _ )/ / /|_  ||_  |
 / / / /_/ /\ \/ _  /_  _/ __// __/
/_/  \____/___/____/ /_//____/____/

PD Stack v0.98
=====================================
TCPM Init
UNATTACHED_SRC
Port[0]: addr: 0x20, DRP, Rp: 3.0A, Flags: Try-SNK.
VID: 0x0451
PID: 0x0422
DID: 0x0100
REV: 0x02
PD Init
TUSB Init Complete
CC status = 0x13
ATTACH_WAIT_SNK
CC status = 0x13
ATTACHED_SNK
tcpm_hal_vbus_enable(port, VBUS_SNK);
PE_SNK_STARTUP
tcpm_mux_controlMux: USB
PE_SNK_DISCOVERY
PE_SNK_WAIT_FOR_CAPS
PD Rx
PE_SNK_EVALUATE_CAPABILITY
PE_SNK_SELECT_CAPABILITY
PD Rx
PE_SNK_TRANSITION_SINK
tcpm_hal_vbus_enable(port, VBUS_SNK);
PD Rx
PE_SNK_READY
PD Rx
PD Rx
PD Rx
PD Rx
PD Rx
PD Rx
PE_SNK_EVALUATE_CAPABILITY
PE_SNK_SELECT_CAPABILITY
PD Rx
PE_SNK_TRANSITION_SINK
tcpm_hal_vbus_enable(port, VBUS_SNK);
PD Rx
PE_SNK_READY

Policy Engine State History:
  [0] SNK_STARTUP
  [1] SNK_DISCOVERY
  [2] SNK_WAIT_FOR_CAPS
  [3] SNK_EVALUATE_CAPABILITY
  [4] SNK_SELECT_CAPABILITY
  [5] SNK_TRANSITION_SINK
  [6] SNK_READY
  [7] SNK_EVALUATE_CAPABILITY
  [8] SNK_SELECT_CAPABILITY
  [9] SNK_TRANSITION_SINK
->[10] SNK_READY

Type-C State: ATTACHED_SNK (last: ATTACH_WAIT_SNK)

Then the device is power cycled (This causes VDD and VCONN to cycle on TUSB422) but MCU remains on and cable remains inserted.  With the power cycle I am re initializing the SW stack.  During this time there appears to be a hard reset on CC.  This results in the SW stack getting stuck in the discovery state and the incoming Source_Cap massages are ignored :

 ________  _________  ____ ___  ___
/_  __/ / / / __/ _ )/ / /|_  ||_  |
 / / / /_/ /\ \/ _  /_  _/ __// __/
/_/  \____/___/____/ /_//____/____/

PD Stack v0.98
=====================================
TCPM Init
UNATTACHED_SRC
Port[0]: addr: 0x20, DRP, Rp: 3.0A, Flags: Try-SNK.
VID: 0x0451
PID: 0x0422
DID: 0x0100
REV: 0x02
PD Init
TUSB Init Complete
CC status = 0x13
ATTACH_WAIT_SNK
ATTACHED_SNK
tcpm_hal_vbus_enable(port, VBUS_SNK);
PE_SNK_STARTUP
tcpm_mux_controlMux: USB
PE_SNK_DISCOVERY
PE_SNK_WAIT_FOR_CAPS
PE_SNK_HARD_RESET
PE_SNK_TRANSITION_TO_DEFAULT
tcpm_hal_vbus_disable(port, VBUS_SNK);
PE_SNK_STARTUP
PE_SNK_DISCOVERY
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);
CC status = 0x13
tcpm_hal_vbus_enable(port, VBUS_SNK);

Policy Engine State History:
  [0] SNK_STARTUP
  [1] SNK_DISCOVERY
  [2] SNK_WAIT_FOR_CAPS
  [3] SNK_HARD_RESET
  [4] SNK_TRANSITION_TO_DEFAULT
  [5] SNK_STARTUP
->[6] SNK_DISCOVERY
TCPC-0 Regs:
10: 00
11: 00
12: ff
13: 0f
14: ff
15: 7f
18: 60
19: 00
1a: 0a
1b: 06
1c: 60
1d: 13
1e: 00
1f: 00
2e: 02
2f: 00
70: 00
71: 00
72: 00
73: 00
74: 00
75: 00
76: 00
77: 00
78: 00
79: 00
90: 00
92: 00
94: 04
A0: 00


Based on the register dump it looks a little like the Hard Reset brown-out has caused the TUSB422 to reset, but not the MCU.

Power Tree

VBUS ---------3v3---MCU

         \----5v--------3v3----TUSB VDD

                   \-----------TUSB VCONN

Is there a way to recover from this (I imagine if I re init the stack I will find myself deadlocked)?

Or maybe is there something I should be calling before I re initialize the stack to prepare the TUSB422?

Note: I am using rev 0.99 of stack despite header printout.

  • 0
    TI__Mastermind 36085 points
    Hello Devan,

    What if you disable Try.SNK and when the TUSB422 connects as source just change the power role to SNK,

    Regards,
    Diego.
  • 0 in reply to Diego Cortes
    Prodigy 130 points

    I am assuming that you are talking about the TC_FLAGS_TRY_SNK flag?  I will try this but I do not think that my device is capable of operating in SRC mode. 

    What appears to be happening is that the 15V VBUS (previously negotiated) is tripping the VBUS OV Alert and generating a Hard Reset.  Ideally I would want the SW stack to realize that the TUSB422 was previously negotiated to the 15V PDO and resume the appropriate state (TCPC_STATE_ATTACHED_SNK?).  If that is not possible, is there a way to instruct the TUSB422 to request vSafe5V before I reset the host?  It appears that Request massages are allowed during an explicit contract but the TI stack doesn't appear to have hooks for this presently.

    Thanks,
    Devan

  • 0 in reply to Devan Lippman
    Prodigy 130 points
    TC_FLAGS_TRY_SNK did not change this behavior.