TUSB8041: HELP - DFP has TERM OFF while enabling VBUS - Enumeration fails (->USB2)

Hi Darren,

Without the UFP trace, it is guess work, but in general when the UFP sees USB_VBUS high and ss.rx.terms, it will turn on DFP VBUS and ss.rx.terms.  There will likely be some delay between the two due to the bulk capacitance on VBUS, which you can see the in trace.  In the hotplug case, we see DFP power get cycled and terms get turned off, this indicates that the upstream port doesn't see the ss.rx.terms, maybe due to entrance to compliance mode or an error state, and the DFP power is controlled by the USB 2.0 side of the hub.  Which SS MUX is in the path?  If the ss.rx.terms are not getting removed during the "unplug" portion of the hotplug that could cause this behavior.

Regards,

JMMN

Hi JMMN,

>>Which SS MUX is in the path? 
The HD3SS3212

The system is (Tablet) <-> TypeC Connector <-> SSMUX <-> TUSB8041I <-> TypeA Connector <-> USB Thumb Drive
A PD Controller watches CC and controls the MUX / Negotiates Power, etc...

I did a little more digging around - and found why there are strange timings on Rx.Detect / VBUS for the DFP.
See these attached waveforms: VBUS Issue - there is a glitch on PWRCTLx causing VBUS to trigger strangely; but no glitch on USB_VBUS.

TUSB8041I has USB_VBUS watching the UFP's VBUS - which goes to the TypeC connector.
TUSB8041I has PWRCTLx set to control the DFP's VBUS - which comes from a 5V rail on the board.
The UFP is the "Power Source" providing VBUS to an external Tablet.

Recall:
- The system boots up and enumerates UFP/DFP as USB3 with no issue (no glitch on VBUS)
- But for some reason, and only with a Samsung Tablet so far, if you power-cycle or unplug/replug the I/F board, it enumerates as USB2 (glitch on VBUS)

Any thoughts...?

・SCL/SMBCLK  → Open
・SDA/SMBDAT → Open
・SMBUSz/SS_SUSPEND → Pull-up
・FULLPWRMGMTz/SMBA1/SS_UP → Pull-Down（Is PD okay？）
・PWRCTL_POL  → Pull-up
・GANGED/SMBA2/HS_UP → Pull-down
・AUTOENz/HS_SUSPEND → Open
・TEST → Pull-down

*Also, EN/Fault from TUSB8041 and Power Switch are not pulled-up to 3.3V or anything...?

EDIT:
Just considered this...based on the 2nd "Hotplug" log I showed above.
If the Samsung Tablet presents, then turns off termination quickly as shown, would the TUSB8041 turn on PWRCTLn for a moment, then realize termination was removed, and turn PWRCTLn off again, only to wait for ~2s before turning PWRCTLn back on, to enumerate USB2?

Regards,
Darren

Hi Darren,

The glitch on the downstream port power is caused by whatever is happening on the upstream port of the hub.  The upstream USB 3.0 connection starts causing downstream port power (and rx.terms) to turn on and then fails for some reason causing downstream port power (and rx.terms)to turn back off until port power is enabled by the USB 2.0 commands.

We would need to see what is happening between the system and the Samsung tablet to know what is causing the drop to USB 2.0.

Regards,

JMMN

Hi JMMN,

I'm trying to decide how to go about analyzing the UFP. (Type-C connectors, but I only have the Advisor T3 - need to make some adapter boards...)
In the meantime, could you answer the below?

[1]
If the TUSB8041 notices low-impedance on SSTX lines (far-end receiver detection) of the UFP,
it will pass that on to DFP by setting it's own DFP-Rx lines to low-impedance. Right?

[2]
But would this be expected behavior even if USB_VBUS was 0[V]? It would could present termination on DFP?

[3]
If yes - then it makes sense once it detects VBUS through USB_VBUS resistor network, it would apply VBUS.
But what we see is that almost immediately, it shuts-off both VBUS and Receiver Termination.

I know we need an Analyzer log of the UFP-side to understand if the Tablet toggling Receiver Termination is causing this...
But would the TUSB8041 immediately shut-down VBUS(DFP) if the Tablet(UFP) disabled it's Receiver Termination at the same time?

Regards,
Darren

HI Darren,

If the UFP sees VBUS on and rx.terms, it will move to rx.detect on the DFPs and turn on downstream VBUS.  If the upstream VBUS is off, the downstream ports should not enable rx.terms.

If the upstream port thinks that the host rx.terms got removed or something, then it would quickly shut off its downstream VBUS and disable rx.terms.  I still dont know what this would happen however.

Regards,

Julie

Hi JMMN,

Still working on getting an Analyzer to check the UFP traffic.

[1]
I reviewed the DFP State Machine for the Hub, and see what you mean.
I did want to point out the DSPORT.Powered-off -> DSPORT.Disconnected state change has an ambiguous comment regarding Rx.Detect and VBUS.
Does the TUSB8041 actually check VBUS before presenting terminations, or is VBUS being ON "implied by Receiver Detection"??

It almost seems like, if the Hub detects Termination on UFP, it assumes there must also be VBUS (UFP), and it could move to DSPORT.Disconnected.
I would be curious how the TUSB8041 actually implements that check when it decides to Present Termination to the DFPs.

[2]
A question about PWRCTL1/BATEN1.
The DS states this pin in PD internally, and the Demo Board (EVM) also uses no external PU/PD. (External PU is used to set BC1.2 support)
However, the pin is "sampled at the de-assertion of reset" -> Is there any time where the pin is in Hi-Z after TUSB8041 is released from Reset?

What would be the typical interal PD resistance on this pin?

Regards,

Darren

1. Our hub will actually check for USB_VBUS, not all competitor hubs do.

2. The internal PD on PWRCTLx/BATENx is disabled after the pin is sampled and switches to output mode.

Regards,

JMMN

Hi JMMN,

1) 
I took a scope shot of UFP VBUS (PD Negotiated), and DFP VBUS(TUSB8041 Controlled) for the channel in question.
The green line was added based on the Advisor T3 Logs - it is TERM = ON/OFF for DFP; and is turned on before UFP VBUS comes in...
It's upwards of 600~800[ms] before the UFP VBUS comes up.

If the TUSB8041 can't turn on TERM until it detects UFP VBUS, but there is none...???
That is the question.

2) If PWRCTLx/BATENx switches to output mode after sampling, is there a "High-Z" time period? 

Hi Darren,

1. Can you share the Advisor logs?  That doesn't match up the hub design.  Even if the hub ignored USB_VBUS, the DFP wouldn't turn on terms unless the host was enabling its terms on an unpowered port?
2. No, the PWRCTL outputs aren't high-z, they will either be high or low.

Regards,

JMMN

Hi Julie,

1) I tried getting some logs again, but for some reason couldn't replicate the TERM-before-VBUS behavior.
Instead, Terminations followed the VBUS.

The attached Presentation shows the two cases -> Good vs Bad.
It looks like the issue really is that VBUS glitch...I'll see how to get an Analyzer on the UFP.

USB_Example.pptx

2. Thanks.

Ok, I've tried a few different things in the lab and I'm not getting anything close to a VBUS glitch unless I have battery charging modes enabled.

I'll direct message you the info on what controls the downstream port power on both USB 2.0 and USB 3.x.

Regards,

JMMN