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.

TPS65987D: PP_HV switches not closing

Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65987, TPD6S300, BQ25792

Hi all,

After correcting the SPI connection to the flash from yesterday, I now have the Duo EVK source board supplying power to my board. However the problem now is that the internal PP_HV switches won't close. I have flashed on my board the Duo EVK sink's demo binary (tps65987_power_duo_mode_SINK_evm_flash_image.bin), so I expect it to behave the same. I have already swapped the flash on the Duo EVK sink with the flash from my board it can boot the EVK sink, and it does. Dumping the flash contents and comparing it to the programmed binary also shows they are the same. So I'm confident the image loaded on the flash is correct.

I have removed everything else on my board, so short of the FT4232HL programmer and the buttons/LEDs, it's (as far as I can tell) identical to the Duo EVK sink, save for the GPIOs which are currently just fanned out to test points.

There is also a TPD6S300 which I've unstuffed and bypassed - again just to eliminate any differences between my board and the Duo EVK sink.

The problem is that I have 5V up to PP_VBUS, but PP_HV1/2 switches are not being closed. The Duo EVK source board's 5V LED also illuminates solid. Yesterday with the incorrectly connected flash, this was not happening. The EVK source 5V LED would briefly flash on and extinguish.

If I no-stuff the MISO pull-up to switch the boot strapping to BP_NoWait/Configuration 5, I get 20V on PP_VBUS and again nothing on PP_HVx. This to me suggests the controller is alive and negotiating contracts.

Inspecting the SPI activity at boot and comparing it to the Duo EVK sink, I don't see anything markedly different

Duo EVK sink

My board

On my board, the CS line goes high when resting as I have a pull-up; the EVK sink does not. Inspecting the first and last few bytes - they match the programmed binary files starting at 0x2800 and ending at approx. 0x9A50, respectively.

Comparing the CC activity, there is discrepancy between what the Duo EVK sink and my board is doing.

Duo EVK sink

My board

As you can see, my board only negotiates a Rev 2 RDO whereas the EVK sink is Rev 3. Additionally, mine asks for only un-enumerated current (100mA), while the EVK asks for 900mA~3A. The EVK also has almost double the transactions taking place after VBUS_UP (42 entries) compared to my board (28 entries).

For convenience and my own sanity, below is an aggregated version of the EVK sink schematic. which I've annotated with highlighting for power nets and various buses.


  • Hi,

    Could you please attach the PD log file here as the image is a little small and harder to read? Also, do you have the analog scope captures of VBUS, PPHV, etc?

    Thank you,


  • Sure thing.

    Here is the dump from the Cypress protocol analyser:

    And here are the scope outputs

    CH1: VBUS CH2: PP_HV, 10ms/div

    CH1: VBUS CH2: PP_HV, 200ms/div

    Also, here is the first burst of CC activity after connection in context of VBUS.

    The source currently supplying this board is the source half of the PD Duo EVK.

  • Hello Arda, 
    Will look into this and get back to you. 


  • Thanks Deepak. Just some more information in the event it's useful. I just received a standalone FT4232H module today so I can program my board without involving the EVK. I can confirm I am able to read the I2C 0x03 and 0x0F registers and the values match that of the Duo EVK sink. This again, strongly suggests the controller is active and responsive.

  • Hey Arda, 

    Thanks for that test, that is awesome to know the controller is active. Currently on a debug, will get back to you early next week on this. 

    - Deepak 

  • Hello Arda, 

    Sorry for the delay in reply. I had been addressing another high priority debug. 
    I would be needing the following:
    1) Can you send me the CC activity of your board and the EVM duo board as separate file.
    2) Can you send me the binary and the project file. 



  • Hi Deepak,

    No worries.

    1) Sure. The custom board's one is the same as what I attached above. Attached again here.


    If you install the EZ-PD analyser utility, you can import these CSVs and have it decode them for you.

    2) I'm not using a bespoke binary/project just yet. It's the demo EVK binary that's supplied with the TPS6598x configuration utility in the recovery folder.

  • Hi Arda, 

    Can perform a test on your custom board:
    1) Use a default configuration and populate a value of your choice in register Customer Use (0x6). 
    2) Load the firmware
    3) Once firmware has been loaded, enter debug mode and check if the values you set in register 0x6. 

    Let me know if it reflects what you set during programming. 


  • Hi Deepak,

    So I'll lay out what I did here.

    1) Project -> New Project
    2) TPS65987DDH
    3) Standard
    4) UFP Only
    5) Set customer use 1 to 0x6

    6) Save binary (Full Flash image) with the following offsets:

    7) Connect FT4232H to SPI and I2C2 headers.
    8) Binary -> Flash from binary file
    8) Unplug/replug PD 
    9) Debug -> Debug Mode

    10) Customer word 1 returns 0x06 as expected.

    EDIT: I also tested on I2C1. Customer word 1 readback is the same.

  • Hi Arda, 

    Thanks for the details on what you have done. It rules out some issue. Also, it proves that the firmware is loaded on the custom board and we can read back values in debug mode. 

    Can you try the following configuration: 
    New project - 987DDH -> Standard -> DRP prefers power source 

    Could you use this configuration and check if PP_HV switch closes. 


  • Hi Deepak,

    With DRP, it does close successfully. So what does this mean? Why does it not close with the Duo Sink's binary, but it does close with a DRP project config? Could this have something to do with my VIN_3V3 pin being connected to a (currently) unpowered LDO? I wouldn't think this would make a difference as there's no voltage being delivered to VIN_3V3 in either case of the LDO being powered, or in the Duo's case, the pin being floating. However if there's undocumented current sensing on the VIN_3V3 which might be seeing the unpowered LDO as a 'load', that might explain things, especially considering that I imagine the Duo's firmware wouldn't have the 'externally powered' option set.

    I'll flash back the Duo's firmware and unstuff the unpowered LDO and see what happens. Ultimately I will need it to work in cases where the LDO isn't powered though, as that would correspond to a dead battery condition. Functionally, this product is essentially a power bank. It's very similar architecture-wise to your discontinued TIDA-01515, but uses a bq25792 instead.

    EDIT: Removing the LDO has not changed the behaviour of PP_HV not closing with the Duo Sink's firmware.

  • Hello Arda, 

    Good to know that with the DRP binary you have a working setup. This rules out hardware and boot issues. The issue has been with the project file setting, using the default project file confirms it. 

    EDIT: Removing the LDO has not changed the behaviour of PP_HV not closing with the Duo Sink's firmware.

    With respect to the Duo Sink's binary, there are lot of unknowns when it comes to the configuration of the project itself. I would strongly advise you to create your own project using the GUI. Reason being you would have to configure GPIO's to control the multiple events. 



  • I mean, sure don't misunderstand me - I wasn't planning on using that binary for production purposes. I already have my own project file that configures the system as a DRP. But it is a little concerning why the demo binary doesn't work on my board, but does on the Duo, despite there being seemingly no difference in configuration. As you can imagine, the potential for other skeletons in this proverbial closet, is quite high.

    You mentioned GPIOs - of course you're right that there are GPIOs specific to my application on this board. However I have also broken out the unused ones on this prototype 'just in case' (you can see them in the board render around the perimeter of the TPS). Some of these GPIOs (for example GPIO13/14/15 which are currently floating) correspond to push button inputs on the Duo. Is it possible these aren't pulled up internally (even they can be configured to do so) in the demo firmware, and the fact that they are floating on my board are triggering some sort of erratic behaviour causing multiple GPIO events to fire? The only thing that makes me doubt this is that the Duo source which is supplying my board, has its 5V LED on solid. If the floating pins on my board were causing erratic switching between 5/9/15/20V, I would expect this to show up on the Duo source board's LEDs. Instead, the 5V from the source is stable - my board will simply not close PP_HV.

    If possible I'd like to understand why there is this discrepancy. Because unexplained differences like this are where future gremlins love to hide.

    EDIT: Another thought - perhaps it has something to do with the chip silicon revision? I had to get my chips from a chinese supplier as I don't need to say, stocking is currently an issue. However I don't see anything on the my chip that would suggest they're experimental chips that leaked out somehow. I had this issue a few years ago with your old Luminary Micro acquired parts. Perhaps that's a factor?

    EDIT 2: I just tried grounding GPIO 13, 14, 15 so they're not floating (they're functionally grounded through 100k resistors on the Duo) and there's no difference. I also tried removing all the unused pullups for I2C interrupts and I2C3 (R11, R12, R13, R14, R15 in my schematic) and the 1M pulldown (R17) recommended in the datasheet in order to make my board look even more like the Duo sink. Still no change - PP_HV is not switched. If I have to proceed by ignoring this problem and just hope that there isn't some bigger one lurking beneath this one, then so be it. However I would consider it very troubling if the manufacturer of this part, TI, is unable to tell me why it is that two (now) seemingly identical configurations of the part have vastly difference performance.

  • Hello Arda, 

    I do totally agree with you on the not knowing the differences. And why it is working when using the default project configurations. 
    I will check with the larger team sometime next week on their thoughts on why they see such differences. I believe it could be the project configurations themselves that is making all the differences you see. Reason being the code on PD controller cannot be changed. There is only one version of code available. The only variable that can change is the App configuration, which is strictly related to configuration. 

    That said, let me mail you if I get word from the larger team. 


  • Thanks Deepak. If it makes things easier, I've exported a simplified version of my schematic that shows how my board is currently configured (DNFs etc).  I also included a summary of the outcomes of this thread.
    5657.USB PD prototype.pdf

  • Thanks Arda, Appreciate it.