• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 35 subscribers
  • Views 976 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.

TPS65982: CC Line Failure

Eric K
Prodigy 80 points
Part Number: TPS65982
Other Parts Discussed in Thread: TPD6S300A, , HD3SS460, BQ25895, TPS65987D, TPS25750, TPS65988

We have made several iterations to our board design in an attempt to fix a failure we have had with the TPS65982's CC lines for quite a long time now. In the previous revisions of our board, we have found that the CC lines (either CC1, CC2, or both) may fail due to plugging or unplugging a VBUS source. After discovering the short-to-VBUS failure mode that the TPS65982 is vulnerable to, we decided to introduce a TPD6S300A in order to protect against this. After adding the protection IC we still experienced these failures, which when it occurs we are unable to perform most negotiations such as VBUS voltage or DP alt-mode. Next, we added a 400CC1206LR-C PTC fuse, PTVS16VS1UR TVS diode, and a NSR20F30NXT5G Schottky on VBUS in an attempt to solve the issue. These changes, along with some fairly significant changes to the layout, seem to have slightly reduced the occurrences of the failure but it is still happening frequently enough to be an issue for our customers.

For reference, we are programming the TPS65982 to have three sink PDOs, one at 12V (preferred voltage for the device), one at 9V, and one at 5V. Additionally, we are using a BQ25895 charge controller, which is where VBUS gets delivered to. We sink VBUS (12V, 9V, or 5V) from PP_HV and when negotiated as a VBUS source we have the BQ25895 in OTG mode and it supplies 5V to PP_5V0. Our device is also making use of the HD3SS460 for DP alt-mode, but this failure mode has been found to occur during a simple power/charging state so we do not suspect this part of the circuit to be relevant. There have been suspicions that some of the failures have occurred while using USB-C hubs, but we have also witnessed them occur when just using a simple USB-C PD source (wall wart).

On the previous revisions of the board I have used a DMM to measure the failed CC lines DC resistance to GND to be near 0Ω (at least 100Ω or less), effectively shorted to GND. I do not have an instance where the failure occurred with the most recent unit with me, but my colleague does, so if you suggest any measurements to be taken he will do so on my behalf (he may even join this thread).

We have used the C_CCn Pin State Register (0x69) to help us determine if the CC lines have failed by seeing what the register reports when there is no VBUS source present (device is unplugged), when a VBUS source is present with the cable in one orientation, and when a VBUS source is present with the cable flipped in the other orientation. When this is done on a working unit where the TPS65982's CC lines have not failed, using a USB-C PD source, we would get something like the following:

$ sudo i2ctransfer -f -y 0 w1@3f 0x69 r5
0x04 0x00 0x00 0x00 0x42     <- this is 0x42000000
$ sudo i2ctransfer -f -y 0 w1@3f 0x69 r5
0x04 0x01 0x05 0x00 0x47     <- this is 0x47000501
$ sudo i2ctransfer -f -y 0 w1@3f 0x69 r5
0x04 0x02 0x00 0x05 0x47     <- this is 0x47050002

However, for the device where the CC lines are damaged we would get something like this (in one or both orientations depending on if both or just one are damaged):

$ sudo i2ctransfer -f -y 0 w1@3f 0x69 r5
0x04 0x00 0x00 0x00 0x21     <- this is 0x21000000
$ sudo i2ctransfer -f -y 0 w1@3f 0x69 r5
0x04 0x00 0x00 0x00 0x21     <- this is 0x21000000

Here CCpinForPD is stuck at 0x00, so is CC1PinState and CC2PinState, and it is stuck in an "Unattached.SNK" state. Whereas with the functional unit it accurately follows if "C_CC1" or "C_CC2" "is CC pin for PD communication", stating the 3.0A advertised current on the respective CC line, and achieves an "Attached.SNK" state as a DRP (as defined in our firmware).

Please let us know if you have any suggestions for how we can either figure out what's going on, or if you have any experience yourselves with this sort of failure how we might be able to fix it. If needed, we are willing and able to provide you with the relevant schematic and layout for you to review.

  • 0
    TI__Mastermind 30000 points

    Hi Erik,

    Thank you for your detailed post. Using register 0x69 is very creative and I have not seen it used in this way. Will keep this in mind for my own personal debug steps in the future. 

    As far as identifying the issue, is it most likely occurring due to an over voltage event on either the CC pins or VBUS. Since it seems like the CC pins are shorting to ground, it is most likely due to an over voltage event on the CC pins. This is likely due to the VBUS and CC pins shorting to one another during an unplug. If this is what is occurring, you can see this using an oscilloscope. Measure VBUS and the CC pins on the connector during a disconnect event, and see if you see the voltage on the CC pins rise to the level of VBUS. If you see this occur, then you know the pins are being shorted together.

    Your ideas of adding the TPD device, TVS diode, and schottky diode are exactly what I would recommend for such an issue. However, non of these devices fully remove the potential risk of damage during a short or surge event on the CC pins. The TPD6S300A isolates the PD controller from the connector during a surge event on the CC pins, but since the tolerance of the TPS65982 is so small, the TPS6S300A may allow for a voltage spike to be presented to the TPS65982 that is slightly above its abs max. Our newer PD controllers have a higher voltage tolerance on the CC pins so this is no longer an issue with protection devices, but the TPS65982 still have the 6V abs max threshold on the CC pins. 

    For your system though I would recommend measuring the CC and VBUS pins to see if you can catch the fault event occurring. If the short to VBUS event is occurring consistently, then it could be a problem with your connector itself having to high of a tolerance allowing for cables to move while still in the connector 

  • 0 in reply to Adam Mc Gaffin
    Prodigy 80 points

    Hey Adam.

    Thanks for the reply.

    > Our newer PD controllers have a higher voltage tolerance on the CC pins

    Do any of these new USB-C PD controllers you're referring to act as a drop-in replacement for the TPS65982?

    > I would recommend measuring the CC and VBUS pins to see if you can catch the fault event occurring

    It would be very difficult for us to capture the event when the CC lines fail and our thought that it is a short-to-VBUS event that is still causing it is just conjecture, unfortunately I don't think we will be able to measure the failure when it occurs due to its rarity and difficulty to reproduce.

    Besides having a look at the tolerance / looseness of the USB-C receptacle on our device, do you have any other recommendations for how we might mitigate or eliminate this issue?

    Best regards,

    Eric

  • 0 in reply to Eric K
    TI__Mastermind 30000 points

    Hi Eric,

    Unfortunately none of our new PD controllers are drop in replacements for the TPS65982.

    As far as mitigating or eliminating the issue, you have already taken the correct steps by adding the correct devices to your system. If the short to VBUS during a disconnect is the problem, then you have already taken the correct steps. The only thing I can think of that could help the performance of the protection device is by refining their layouts. i.e. increase number of connecting via's, copper area, etc...

    However, since we do not have any waveforms of the failing event this is just conjecture. The CC pins being shorted to GND is an aftermath of the problem but not the problem itself. I am confident in my assumption that the failure is due to an over voltage event on the CC pins which is most likely due to a short to VBUS. But there is no way to know for sure unless we see the failing waveform

  • 0 in reply to Adam Mc Gaffin
    Prodigy 80 points

    Hi Adam,

    If we make it so that the negotiated VBUS voltage can only be 5V then I presume this should completely eliminate the failure mode (assuming it is due to a short-to-VBUS), correct? Unfortunately, this would impact the charging performance of our product, but given what you have outlined this may be necessary.

    Additionally, if we limit VBUS to 5V but still see this occurring, then that may indicate something else.

    Could you share with me what the new USB-C PD controllers are that you referred to? We may consider using them instead in a future revision.

    Best regards,

    Eric

  • 0 in reply to Eric K
    TI__Mastermind 30000 points

    Hi Eric

    Yes that is correct. If you limit your source capabilities to 5V, the chance of damage due to a short to VBUS event is pretty much eliminated. However, I did not suggest this as an option since it would reduce the end performance of your product to resolve an issue that occurs very infrequently. But that is an option you can take.

    If you do see the issue still occurring though after limiting to just 5V, then yes it could be something else. But there is no way to know for sure what that something else would be unless a capture was taken during the failing event. 

    The latest single port PD controllers are the TPS65987D and the TPS25750. If your system is only providing power and does not need to support any alternate modes such as DP, I would recommend the TPS25750. This device actually doesn't need external protection as the VBUS and CC pins are rated to 28V and 26V respectively. 

  • 0 in reply to Adam Mc Gaffin
    Prodigy 80 points

    Hey Adam,

    For the TPS65987D it looks like its CC1 & CC2 pins still have a max rating of 6V.

    > If your system is only providing power and does not need to support any alternate modes such as DP

    We require DP alt-mode support (with the use of the HD3SS460) and require PD dual-role port (DRP) capabilities. Are there any USB-C PD controllers you have which satisfy this but also have a high max voltage rating on the CC pins?

    Best regards,

    Eric

  • 0 in reply to Eric K
    TI__Mastermind 30000 points

    Hi Eric,

    Yes, the TPS65987D has a similar max voltage to the TPS65982, but the internal architecture is different to where it can withstand more current flow through the internal diode allowing for better performance to potential transient spikes. The TPS6S300 was designed with the TPS65987D and TPS65988 in mind