TPS65982: TPS65982 not detecting USB Connection

Part Number: TPS65982
Other Parts Discussed in Thread: TPS55288, TPS65981, TPS65986


I am using TPS65982 to control charging modes for a USB-C device. This chip is new to me and I am currently going through the learning curve to make it operational. The Application Customization Tool GUI is being used to create a .bin file to program a flash chip (W25Q80) with SPI. I am able to get USB-C device charging at about 1.1A at 5V or 500mA at 12V but I cannot get a cable connection detected. The board is powered with 5V(VIN_Z = PP_EXT). PP_HV under normal operations should be 20V powered from a TPS55288 chip, but this also won't work. For testing I have bypassed the TPS55288 chip and have been providing 12V as source input into PP_HV. When I read the Status register, it is indicating that no USB connection has been made. It is also showing a fault on the PP_HVswitch. I believe a lot of the issues I am seeing are due to the lack of cable detection, and possible wrong GUI configuration.

Schematic, Register dump, and GUI settings are attached below.

When I created a new project I selected the TPS65982(NRND) -> Standard -> None -> Dual Role Port(DRP) prefers power source.

When configuring the settings in the Application Customization Tool GUI, I am a bit confused on the wording of some of the options. In GUI on the System Configuration area, PP_5V0 can only be disabled or set as an output. In the TPS65982 datasheet on page 91, PP_5V0 looks like an input. In our setup PP_EXT(5V), PP_5V0, and PP_HV(12V) are all inputs, yet if I set try to set these as an input my USB-C device does not charge. In our application VBUS should be the only output, unless I am misunderstanding how these are labeled as inputs or outputs.

What exactly is PP_HVE, it is listed in the GUI but not the datasheet. It seems to be related to PP_EXT, when PP_HVE is set as an output by itself, it can charge my USB-C device.

I am also confused how the TPS65982 chooses which source to power a USB-C device from? When I disable PP_5V0, and set PP_HVE as an output, I can charge a USB-C device from PP_EXT(VIN_Z), but when I turn both PP_5V0 and PP_HVE as outputs, the USB-C device only charges from PP_5V0. When I turn off the power source to PP_5V0, PP_HVE will not switch to start charging the USB-C device. The inability to mux right now is probably due to the cable connection not being detected.

I believe the C_CC pin configuration may be responsible for detecting cable orientation but why might the TPS65982 not detect a cable connection at all?

For the register values I referenced  the TPS65981, TPS65982, and TPS65986 Host Interface Technical Reference Manual.

Before USB connection the Status register (0x1A) reads 0x60000400, a 4(0100) in the 2nd byte, bits 11:10, indicates "PP_HV switch currently disabled due to fault (system output).". I can't figure out what would be causing this. 00 in the first byte indicates that no plug is present.

After a USB connection is made the Status register reads 0x6d022400. The PP_HV switch is still disabled due to a fault. The first byte still reads 00 with no plug present.

Could the PP_HV fault be causing the lack of cable detection?

Attached below is the Schematic for how the TPS65982 is connected.


Here is the configuration settings I used for the TPS65982. The application GUI would not let me save the project due to an error that I could not resolve, so I saved screenshots and zipped them.

Application Custimization

Here is the Register output for no USB connection Vs a Connected device.


  • I do agree that the reason the USB cable orientation is not being detected because of some power issue either in the schematic or in the configuration. If you can, please send a PD log from a USB Power Deliver Analyzer when you attach a device. It may help to show if the device attempts to connect before shutting down.

  • Unfortunately I do not have access to a USB Power Delivery Analyzer. I will look into getting one.

  • If a PD Analyzer is not available, if you can probe the CC line to see if there is any changes besides the initial connect.

  • I am really leaning towards the PP_HV switch fault being the culprit. What could cause a fault on this line? I have completely disabled the PP_HV line in the GUI and the fault still remains. I have tried just about every setting to configure this chip and have not been able to get past this fault.

    I was able to monitor both CC lines. 

    I noticed when I had the cable in direction 2 when connected to the TPS65982, I could flip the cable on the device side and no changes were seen on C_CC1 or C_CC2.

    Below are the screen captures.

  • I agree the PP_HV fault is the issue now. I will be out on Monday for holiday so responses will be delayed. I will review the TPS65982 documentation and get back to you Tuesday

  • Ryan,

    Can you please do the following:

    1) Try to get a PJT to save and share it here. I am unsure why it would have issues

    2) Under System Configuration (0x28) Enable 'ILIM Disabled for PP_EXT' and Set PP_EXT Configuration to 'PP_EXT configured for output'

    3) When device is running and you are connected to it through the GUI, enter debugmode from the top of menu of the GUI then go to Decive 1, port 1 -> Commands -> DBfg - Dead Battery Flag Clear -> Execute DBfg

    4) Go to Debug registers -> Mode (0x3) -> Read the value here (Can be done without GUI)

    Step 3 can also be done without a GUI but may require a bit more involvement.

  • Hello Christodulos,

    I was able to get a PJT to save finally, had to run the app as an Admin. See attached below.

    I was able to connect to the GUI, I have wires hanging off of the pull up resistors connecting to an Aardvark adaptor. The GUI shows a completely different readout on the registers. It shows that the plug is making a connection and but there still is a fault on the PP_HV switch.  I need to get some more time to fully dive into this now with the GUI. It still doesn't seem to be power muxing.

    The Mode register reads 0x20505041 which is APP mode, this is what it was reading before.

    The Status register 0x1A reads 0x4006D.

    The DBfg Flag clear command is denied.

    Overall this seems to be good news, but I'd like to be able to read the same values when I am not connected to the GUI.

    DRP Prefer Power Source_ILIMdisabled.pjt

  • Glad the GUI is working!

    APP mode is good. I would recommend using some type of I2C logger (Total Phase/Saleae) to capture the I2C transaction read format so you can replicate the GUI I2C transaction.

    With the PJT I can try to replicate the issue in my EVM. While I get that ramped up, could you take a register snapshot (Enter debug mode -> Click Debug from top menu -> Take snapshot) while the device is connected?

  • From the snapshot, the Debug registers snapshot shows that there is a connection and the connection is using PP_5V

    Status (0x1a) - (0x24026d)
        Plug Present           Plug present, see Conn State (below) for details. (0x1)
        Conn State             Connection present, no Ra detected (Rd but no Ra) or Rp detected with no previous Ra detection, includes PD Controller that connected in Attached.SNK. (0x6)
        Plug Orientation       Upside-up orientation (plug CC on C_CC1) or orientation unknown or port is disabled/disconnected. (0x0)
        Port Role              PD Controller is Source (C_CCx pull-up active). (0x1)
        Data Role              PD Controller is DFP. (0x1)
        VConn Enabled          VConn not supplied by this controller (0x0)
        PP_5V Switch           Enabled Reverse current from VBUS to Power Path blocked (acting as output) (0x2)
        PP_HV Switch           Disabled (0x0)
        PP_HVE Switch          Disabled (0x0)
        PP_Cable Switch        Disabled (0x0)
        Overcurrent            False (0x0)
        Power Source           VIN_3V3 (0x1)
        VBUS Status            VBUS is at other PD-negotiated power level and within expected limits. See ADC Results for exact voltage provided multi-channel ADC is active. (0x2)
        USB Host Present       No far-end device present providing VBUS or PD Controller power role is Source. (0x0)
        Acting as Legacy       PD Controller is not in a legacy (non PD mode). (0x0)
        Go To Min Active       No PD contract established or GotoMin restriction has been cleared by Source Capabilities message or disconnect/Hard Reset. (0x0)
        BIST                   No BIST in progress (0x0)
        High Voltage Warning   PD Controller operating as Sink or VBUS voltage is below limit specified by HighVoltageWarningLimit register or port is disconnected. (0x0)
        Low Voltage Warning    PD Controller operating as Sink or VBUS voltage is above limit specified by LowVoltageWarningLimit register or port is disconnected. (0x0)

    I think the PD is working fine but the I2C read handling are not being done correctly since the GUI is able to pull this information form the PD. Check what and how I2C communication is done outside of the GUI.

  • Yes I noted this in a couple responses ago, but the behavior while connected to the GUI is different than when the memory is programmed with the binary file with this same configuration. While not connected to the GUI, the status register list a fault on the HV switch and no plug present. Another issue I am seeing is that our device will not charge on both sides of the USB - C cable on the charger side. I can flip the cable on the device side and it charges both sides, but on the charger side it will only charge in direction 1 when referencing the CC line screenshots. There is something going on with direction 2 orientation where it does not see when the device is connected and no changes are seen to the CC lines the moment the cable is plugged into the device side. I haven't had much time this week to debug further, I will try some things out on Monday. 

  • Ryan,

    What steps are you doing to load the configuration from the GUI? Are you loading the config using Binary -> Flash from Current Project?

    Also the type-c cable having issues with the orientation is odd. Have you tried other cables? There is no glaring issues in the schematic I could see on the CC_1/CC_2 wires.



  • I load the software by saving a binary file and using an aardvark SPI programmer to load the binary data onto the flash chip(W25Q80). The  steps to load the file to flash are:
    1.) Save .bin file from Application Customization Tool. Binary -> Check the "Low Region (Full Header)" -> Change File -> OK

    2.) Open Flash Center, choose Aardvark adapter, choose W25Q80 flash, then Program + Verify. If verify fails I erase and program again until it succeeds.

    I did do some test to see if the changes in the configuration were being taken by changing the output power from only PP_EXT to only PP_5V0. In my setup these two outputs are powered by two separate power supplies and depending on which is chosen, there will be different current draws on the power supplies. The issue I am seeing is that when both PP_EXT and PP_5V0 are set as outputs, if I turn the power supply going to the PP_5V0, the power source does not switch to PP_EXT. I'm not sure if I understood this wrong, but I thought it should have the ability to switch(mux) sources depending on what is available.  I thought the fault I was seeing on PP_HV switch was the cause of this, but that fault seems to have disappeared while connected to the GUI.

  • Ryan,

    I am concerned about the fact that the Program + Verify fails enough for this to be an issue. I would suggest doing a Flash Read from the GUI and comparing the .bin read from the PD. This may be a flash issue.

    Assuming the flash is NOT an issue, then the PP_5V0 and the PP_EXT are meant to be configured for specific power paths. The user is supposed to specify and the PD does not switch to one or the other based on what is available.

  • I'm not sure why it fails some times, but the verify is basically a read/compare to the original bin file. When it does fail, and I do a verify, it also fails. But  when i get a successful load, I can verify and it matches the bin file. I can even dump the flash and compare to the original bin manually and it appears to be the same. I definitely don't start testing the TPS65982 after a failed flash load. I wait for it to successfully load, then I reboot the board for the changes to take effect.

    If the user is supposed to specify, why is there an option to set all of the different outputs to be enabled at once? If a device can't support fast charging, it should use PP_5V0  at the correct amperage. If it can support fast charging, PP_HV or PP_EXT should be used to supply the device with the higher voltage and amperage. Please correct me if I am wrong. This is why I thought it should be able to switch between power modes. This seems to be mentioned on page 4 in the description in the datasheet.

  • Ryan,

    Let me make sure I have these PP_ settings correct:

    You have PP_HV connected to the power supply (PP_HV is used in Source mode)

    You have PP_EXT connected to a different power supply (Also only used in Source mode)

    What I am saying is if the device is in a Source role and the current PDO (Source Capabilities) Switch Source is PP_HV, then turning off the PP_HV would cause a disconnect. The PD will not switch to a different negotiated contract when PP_HV goes away.

    Alternatively, I would expect that if a PDO is selected and it's Switch Source is PP_HVE (PP_EXT) then disconnecting PP_HV should not cause issues. Side note, PP_5V0 is used to power the VCONN between CC lines so this is important to always have at 5V

    As for the device not behaving as expected when not connected to the GUI, I know the GUI only queries the PD or reprograms the EEPROM if told to, how are you connecting the GUI to your system? Typically, this should not interfere with the PD operation.

  • I have the CH1 I2C lines of the TPS65982 connected to the Aardvark Programmer, the GUI then can connect to the TPS65982.

    When not connected to the GUI I use the same I2C lines with a PIC microcontroller that sends read commands to specific registers and I can see that the values are different than what the GUI had listed. 

    To prevent the PIC and Aardvark from both driving the lines I erase the PIC and connect the Aardvark, or I disconnect the Aardvark and program the PIC.

    I know that the data is good when reading from the PIC because most of the registers are the same as the GUI, such as being in APP mode, but specifically the 0x1A register I see the PP_HV switch fault as well as no plug connection still.