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.
Part Number: TPS65981
I'm encountering an issue revolves around never regaining connection to a downstream device at the port controller by the TPS65981 after the upstream connection is lost and re-established. For instance, in the diagram below if you disconnect and reconnect cable 1 the host will usually not rediscover the device. However, if cable 1 is connected prior to connecting cable 2, there isn’t any issue. In a failure condition I can only recovery by reconnecting the device at the DFP.
Host <-----cable 1-----> UFP <-> Hub(TUSB8041) <-> DFP (TUSB546-DCI controlled by TPS65981) <-----cable 2-----> Device
There are 3 other DFPs coming off this hub, which all use a different mux/controller (HD3SS3220). None of these DFPs experience this issue. Additionally, the problem has been observed with multiple hosts and devices. In fact, the problem seems to be somewhat dependent on a race condition in some form. For instance, I can reliably replicate problem when plugged directly into the host, which is a laptop, but when I route it through the laptop dock I don’t see an issue. Additionally, there have been a very small number of instances when the device is rediscovered after a UFP reconnect in a previously failing case.
I have checked the DFP mux and it maintains it's correct orientation when the UFP is disconnected. Nothing seems strange here.
I have the following questions that might help provide some insight into the issue:
1. Are there any firmware settings for the TPS65981 that are not accessible in the Application Customization GUI? In an effort to troubleshoot I’ve played around with most available firmware settings. This includes changes to USB Suspend options since we originally thought there were issues with the way the host was commanding suspend and wake to the device. If there are any more private settings to influence I’d be interested in learning more.2. Are there any documented known issues with this PD controller? Any known issues document would be helpful here.3. Are there any private GPIO events available that are not already accessible in the Application Customization GUI? Ideally, I’m looking for a GPIO event that would identify when an upstream connection was re-established. This might make is easier to manually trigger a refresh of the downstream connection when the upstream cable is reconnected. Right now there isn’t anything available in the firmware settings like this. The PD controller seems to have no knowledge of what’s happening upstream.
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Prajith Cheerakkoda:
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.
In reply to Will Kay:
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?
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.
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.
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.
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?
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:
Please provide your email address for further communication.
Please contact me at firstname.lastname@example.org
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.