TPS65981: Inconsistent PPHV path pass through

Manikandan M V

Part Number: TPS65981

Hi,

We have our TPS65981 make boards and flashed the application image to it. Below is our application information.

Our application is 5V/2A sink which intends to pass power from VBUS to PPHV when standard USB-C PD complaint sourcing device is connected. So we tied BUSPOWERZ to 3.3V to disable the 5V pass to PPHV unless PD negotiates 5V/2A from the source.

When connecting NuPower PD adapter, we got 5V pass-through on PPHV, but not always. We're not seeing 5V output on PPHV during continuous plug/unplug. With Pixel Phone Charging Adapter also, the behaviour is same. Captured snaps in debug mode are here. With NuPower Adapter.zip With Pixel Phone Adapter.zip

Regards,

Manikandan

over 7 years ago

0 Eric Beljaars over 7 years ago

TI__Mastermind 36756 points

Hi Manikandan,

If you are a Type-C Sink, and want to sink on PPHV. I would recommend tying BUSPOWERZ to 1.8V. If you have it connected to 3.3V you will never close the PPHV FET while in a dead battery condition. I am assuming that your SINK board is powered from VBUS-PPHV. If that is the case, please connect BUSPOWERZ to 1.8V so that PPHV FET will close.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
Our application has to be bus powered (power-up from dead battery condition) only from the standard USB-C source ports (say USB-C laptop, PD power adapter) not from the legacy USB A devices.
If I tie BUSPOWERZ to 1.8V, USB-A laptops are powers our board (PPHV path closes) which is undesired behavior.
Also, tie the BUSPOWERZ to 3.3V closes PPHV from dead battery state. However, this PPHV path closure is not happening always. On this scenario I have shared the logs above.
Could you provide me a configuration solution which works only with 5V/2A PDO sink?

Thanks.

0 Eric Beljaars over 7 years ago in reply to Manikandan M V

TI__Mastermind 36756 points

Hi Manikandan,

Tying BUSPOWERZ to 3.3V will not close any of the power paths until the SPI flash configuration has been loaded onto the device. After it has loaded the configuration, it should then close the PPHV for a PD Source.
I noticed in your configuration file that you have 2 Sink Capabilities set. One of them is for 5V/0.9A and the other is for 5V/2A. You should remove the 0.9A one and only have a 2A one if you only want to accept a 5V/2A source. You can do this by setting the minimum operating current to 2A.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
I have changed to single 5V/3A sink PDO and removed 5V/0.9A PDO, yet the PPHV path closure remains inconsistent.

Thanks.

0 Eric Beljaars over 7 years ago in reply to Manikandan M V

TI__Mastermind 36756 points

Hi Manikandan,

Do you have a PD analyzer available? It may be helpful to observe the PD communication for the failing case.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
I do not have PD Analyser. Any other approach to diagnose the PD communication failure case?

Thanks

0 Eric Beljaars over 7 years ago in reply to Manikandan M V

TI__Mastermind 36756 points

Hi Manikandan,

Do you have an EC available in your system? This would give you much more flexibility when selecting different PD contracts.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
Sorry I'm not aware of the EC on the Laptop end. Actually, I'm using TI application customizer tool for flashing and debugging.
Kindly let me know in detail about the EC which you have meant for monitoring the PD activity.
Thanks.

0 Eric Beljaars over 7 years ago in reply to Manikandan M V

TI__Mastermind 36756 points

Hi Manikandan,

I was asking if you had an embedded controller on your board with the TPS65981. This would allow you to select and change PDOs during run-time.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
Yes, we have Myriad SoC on board which communicates with TPS65981 through I2C. Actually, we have not started developing driver for TPS65981 side. However, you advise the process to the fix the PD communication failure through run time configuration.

Thanks.

0 Eric Beljaars over 7 years ago in reply to Manikandan M V

TI__Mastermind 36756 points

Hi Manikandan,

Great! In this case, you can configure PP_HV to "input, wait for SYS_RDY command". This would make it so that PP_HV does not close unless the SYS_RDY command is sent by your Myriad SoC over I2C. In this case, you could review the Source PDOs sent by the device connected to the Type-C port and only send the SYS_RDY command once sufficient power has been negotiated. You could review the Active Contract PDO (0x34) register over I2C to see what power has been negotiated. The Host interface technical reference manual covers all of the registers available over I2C as well as the 4CC commands you could send to the TPS65981.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
Good to know this feasiblity. Our board is bus powered, Myriad SoC is powered from the PPHV output 5V. So before PPHV closure, we don't have any active controllers to monitor & control the TPS65981.
Simply, we require 5V/3A negiotated PD output from PPHV path always when connected with PD devices and then power the rest of our board through PPHV.

Thanks.

0 Eric Beljaars over 7 years ago in reply to Manikandan M V

TI__Mastermind 36756 points

Hi Manikandan,

In this scenario, you could use the 1.8V BuspowerZ configuration to boot the embedded controller. You could then monitor the PDO voltage and current to see if this is appropriate for your system.

Thank you,
Eric

0 Manikandan M V over 7 years ago in reply to Eric Beljaars

Intellectual 420 points

Hi Eric,
Okay, would work for this feasibility.

Thanks.

Interface

Interface forum

TPS65981: Inconsistent PPHV path pass through