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.
In reply to Will Kay:
any reason transfer to HSSC?
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 Brian Zhou:
I don't fully understand your question. Could you provide some more context please.
Thanks for providing the traces, that is very helpful. From the failing trace, the port status on the failing port (Port 1) is stuck in polling. That is consistent with the downstream device on that port having gone to compliance mode. The downstream device will enter compliance mode if it has VBUS on and sees upstream rx.terms, but no polling activity from the hub. When cable 1 is disconnected, can you check for rx.terms on the rx pins of Port 1 of the hub? Just measure from the pin to ground - if it 50 ohms, the terms are on. By design, the hub rx terms should be off, if they are then check if the terms are enabled on the TUSB546.
Another thing to try is to change the setting of the FULLPWRMGMTz pin on the hub, this will cause the hub to send warm resets during power-off preventing entry to compliance mode.
In reply to 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?
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.
I'm marking this as resolved, but if you have any further questions just post them and the ticket will reopen.
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?
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.
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.