TPS65981: DFP through hub will not reconnect after UFP lost

Hi Will Kay, Looks like PD controller is not aware of UFP connect/disconnect. Is there a mechanism (Hub communicate with PD controller on connect) to inform PD controller on UFP connect? Please check. 

Thanks

Prajith  

Hi Prajith,

There is not a built-in mechanism in the hub to inform the PD controller of a UFP reconnect. Additionally, the PD controller GPIO pins do not have any events that correspond to identifying a UFP connection. You can see the available GPIO events in this doc:http://www.ti.com/lit/ug/slvuah7b/slvuah7b.pdf

If there was a GPIO output event that would drive the line when a upstream connection was made then I would use it help configure the DFP mux. Unfortunately there doesn't seem to be such an event, which is the premise of my third question in the original post.

There are however some methods of doing some sort of DFP reset when the UFP connects. I could connect the UFP PD controller's mux enable GPIO line to the reset of the DFP PD controller. This would hold the DFP in reset until the UFP sees a connection. I could also AND the UFP and DFP mux enable signals before routing them to the DFP mux. This would also ensure that the DFP doesn't make a connection until after the UFP connects. However, both these options are roundabout methods of resolving the problem. Ideally, the DFP should be able to re-establish a connection after a UFP reconnect without having to manually force a reset. 

Hi Killy, I would like to know the DFP(both pass and fail DFPs) port status during disconnect. Please capture the USB trace of the DFP and share with us. May I know what device is connected to the faulty DFP port (USB2/3)? Have you tried to repro issue using the devices on passing DFPs? 

Thanks

Prajith 

Hi Prajith,

I've attached 3 wireshark captures. "Bad DFP - Failure" shows the failure condition. "Bad DFP - Success" shows the rarer case where the problematic DFP does allow the device to re-enumerate when the UFP is disconnected then reconnected. I am usually only able to get this to succeed with some host ports or when cycling the UFP connection quickly. "Good DFP - Success" shows a different DFP on the hub that never shows the problem.

The failing condition shows just 3 lines, ending in a response by the device. From these traces it seems like the host should be making a request on line 4, but that just never happens.

I have also taken traces of the PD communication on the CC lines in the past would you like to see those as well? Ultimately, there was nothing interesting here. In all situations both the UFP and DFP PD controllers successfully negotiated PD roles. There is no difference between the failing and successful CC traces. This is also confirmed by the DFP mux remaining unchanged during a UFP connection cycle. The mux control signals remain constant and the PD trace shows no traffic on the DFP during a UFP connection cycle. This seems to make sense given that the UFP and DFP have no dependency on each other and there is no trigger to renegotiate the PD contract on the DFP.

The device I am reproducing behavior with is a USB 3.0 flash drive. I've also reproduced this with a sata drive connected through a USB-sata bridge. I have attempted to reproduce the bad behavior on the three other DFPs that seem to work and have never been able to force a failure. When cycling the UFP connection those three DFPs re-enumerate their devices correctly. In some cases it may take some time (up to 15 seconds) but they always do re-enumerate.

Wireshark Traces.zip

Hi Killy, Wireshark trace is not helpful as we need the trance b/w Device and Hub DFP. As per my understanding DFP transitions to DSPORT.Powered-Off state (logical powered off state) when UFP disconnect happens. I'm communicating with Hub team to get their views on this issue. Meanwhile, please capture USB3 trace b/w DFP and device if you have an analyzer (Lecroy, Ellisy...) with you. 

Thanks

Prajith 

Hi Prajith,

I don't have a USB 3.0 protocol analyzer readily available, but I am attempting to track one down. I will follow up soon when I have more information.

In the meantime, are there any steps that I can take that don't involve this trace? It's possible that there might not be a protocol analyzer available to me at all.

Thanks,

Will

Hi Will,

Please let me know the status of bPwrOn2PwrGood field in your Hub descriptor. 

Are you seeing any electrical activity on Tx/Rx lines after UFP disconnect? 

Thanks

Prajith 

Hi Prajith,

I have the USB traces that you requested. They were captured with a Lecroy Voyager M3i. You'll see in the attached files I have traces while the analyzer was in series with the failing DFP and one of the working DFPs. I also connected it in two configurations. The traces labeled "upstream" are with the analyzer connected in between the host and the UFP. The traces labeled "downstream" are with the analyzer connected between the DFP and the device. In all traces the recording started just before the UFP was reconnected to the host. You'll notice that there is not a trace for failing DFP with the analyzer connected between the DFP and the device. This is because no traffic was read in this situation.

This lack of traffic was also confirmed with an oscilloscope. There is no electrical activity when cycling the UFP connection in a failing condition.

The bPwrOn2PwrGood descriptor for the hub (both the 2.0 and 3.1 hubs) is "50 * 2 milliseconds".

Oops, it looks like the forums won't let me attach files this large and compressing them doesn't help too much. Here is a google drive link where they can be downloaded:

drive.google.com/open

Thanks,

Will

Hi Willy,

Please provide your email address for further communication. 

Thanks

Prajith 

Hi Prajith,

Please contact me at will.kay@ni.com

Thanks,

Will

any reason transfer to HSSC?

Hi Brian,

I don't fully understand your question. Could you provide some more context please.

Thanks,

Will

Hi JMMN,

Thanks for your response! With cable 1 disconnected the rx terms are off when measured at port 1 of the hub. However, they are on when measured at the downstream rx lines of the TUSB546 mux. This explains why the downstream device was entering compliance mode.

I disabled the FULLPWRMGMTz setting and this resolves the problem! Disabling this feature shouldn't affect the system since the VBUS switching isn't actually controlled by the PWRCTL signals from the hub. The problematic DFP instead relies on the VBUS switching internal to the TPS65981. Given that, disabling full power management should be a suitable solution for us.

Just to get some further background, is the intent of sending these warm resets specifically to combat this scenario where the power control is operated by something other than the hub itself? Or is there another purpose for allowing or disallowing the warm resets?

Thanks,

Will

Hi Will,

The hub will drive PWRCTL pins regardless of FULLPWRMGMTz setting.  All FULLPWRMGMTz really controls is what the hub reports as the power on timing value in the USB descriptor and what happens when the SS ports are logically off.  It changes the powered off behavior from DSPORT,Powered-off to switching between DSPORT.Powered-off-detect and DSPORT.Powered-off-reset to keep USB 3.0 devices from going to compliance or dropping to USB 2.0.  I copied the state machine directly from the USB 3.x spec.  If there are no issues for your application with warm resets on the other ports, this should be a good fix.

Can you confirm there are no issues when you connect cable 1 to a USB 2.0 only host?  I just want to confirm the USB 3.0 devices still drop to USB 2.0 when they should.

Regards,

JMMN

HI Will,

I'm marking this as resolved, but if you have any further questions just post them and the ticket will reopen.

Regards,

JMMN

Hi JMMN,

As you suspected, there is an issue with a 3.0 device not connecting when only a 2.0 upstream connection is present. This is true only for the DFP that uses the TPS65981, the other DFPs allow the 3.0 device to make a 2.0 connection properly. Additionally, this seems to be the case regardless of the state of FULLPWRMGMTz. I was just not noticing it before since my attention was on re-establishing a 3.0 connection after a UFP connection cycle.

Based on your previous post it sounds like this port will only connect with 2.0 when it enters DSPORT.Powered-off state and the device is also not in compliance mode. Is that correct? What can we do to ensure that it enters this state?

Thanks,

Will

HI Will,

I'm asking a coworker familiar with the TUSB546 to review this.  There isn't anything more we can do from the hub standpoint, since the hub is turning off terms as expected.  We need to get the terminations turned off on TUSB546 to get the devices to drop to USB 2.0 and avoid entering compliance.

Regards,

JMMN

Will

The TUSB546 can only monitor the physical layer conditions like receiver termination, electrical idle, LFPS, and SuperSpeed signaling rate to determine the state of the USB3.1 interface. Depending on the state of the USB 3.1 interface, the TUSB546-DCI can be in one of four primary modes of operation when USB 3.1 is enabled (CTL0 = H or CTLSEL0 = 1b1): Disconnect, U2/U3, U1, and U0.

The TUSB546 will remain in Disconnect mode until far-end receiver termination has been detected on both UFP and DFP. The TUSB546 immediately exits the Disconnect mode and enter U0 once far-end termination is detected.

I would recommend that when cable 1 is removed at the UFP port, the PD controller should remove the VBUS at the DFP port. The device, in turn, should then remove its termination as well. 

I would also recommend that when cable 1 is removed at the UFP port, the PD controller write 0 to both CTL0 and CTL1 of TUSB546 to place TUSB546 into the Power Down state.

Thanks

David 

Hi David,

Thanks for your response. Your suggestions seem like they would address the issue of the DFP not reconnecting after the UFP is disconnected then reconnected, however I'm not sure that it would address the issue of a USB 3.1 device never downgrading to a USB 2.0 connection when only a 2.0 UFP is available. Even if VBUS was removed and the TUSB546 was placed in Power Down state during a UFP disconnect, when everything is plugged in again the TUSB546 would still present RX terms and prevent the device from downgrading to USB 2.0.

It seems like the mux is only focused on monitoring the USB 3.1 DFP interface and will not change at all based on the upstream connection from the hub. Additionally, the PD controller doesn't have any concept of this upstream connection either. From my investigation of the PD controller events, there are no available gpio events related to the upstream connection (which makes sense because it doesn't even have an interface to the upstream lines, that's the mux's job). Because of this there is no way for PD controller to write 0 to CTL0 and CTL1 of the mux in order to place it in power down state when there is no upstream 3.1 connection.

Am I misunderstanding anything here? There doesn't seem to be a clear way for the PD controller to see that there is no upstream 3.1 connection in order to pass that info along to the mux.

Thanks,

Will

Hi Will

When connected to a USB 2.0 host, would you please check the RX termination on the hub downstream RX, TUSB546 RX downstream RX, hub upstream RX, and TUSB546 upstream RX? 

Do you have a way to probe the SuperSpeed signal between the TUSB546 and the device to verify the device is in compliance mode?

The TUSB546 should only enable its RX termination when far-ended termination has been detected.

Thanks

David

Hi David,

Here is the state of RX termination when the UFP is connected to a 2.0 only host.

hub downstream: terms disabled

TUSB546 downstream: terms enabled

hub upstream: terms enabled

TUSB546 upstream: terms disabled

I've taken a capture between the TUSB546 and the device. I started the recording then plugged in the device. You can see that it seems to actually not be entering compliance mode. It looks like it's ended up in the Polling.LFPS state. Here is the diagram of this setup:

Host (Type-A 3.1 port) <----- cable x (Type-A 2.0 plug to Type-C plug) -----> UFP ---- Hub ---- DFP (TUSB546) <----- cable y (Type-C to Type-A adapter) ---- [<--- cable z (Type-A to Type-B) -----> LeCroy USB Analyzer <---> Device (Type-A USB 3.1 flash drive)

The key factor in this setup that should force the 2.0 connection is cable x. It only has 2.0 pins.

USB traces can be found here:

Will

Sorry for my late reply as I was OOO last week. Does the below diagram correctly capture my understanding of the termination?

Thanks

David

Will:

   any update?