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: With no contract, 5V is appearing on PP_HV1 for sink design

Part Number: TPS65987D
Other Parts Discussed in Thread: TIDA-050014

Our TPS65987D is configured as a sink design with a SPI flash for configuration (similar to TIDA-050014).  The flash is programmed for the default 5V contract and a 15V contract.  The USB_D+/- signals are intentionally not connected to the TPS65987D in our design because we do not want to support 5V charging in our application.

When we connect to a USB-C charger, the 15V contract is made and we see the PP_HV1 output start at 5V, then ramp up to 15V like it should.

When we connect to a standard USB 2.0 port on a PC, we get inconsistent behavior as follows:

1) Sometimes the PP_HV1 stays at 0V, which is what we want.

2) Sometimes the PP_HV1 quickly switches on immediately and produces 5V.

3) Sometimes the PP_HV1 starts at 0V, then 5-10 minutes later switches to 5V for an unknown reason.

When PP_HV1 is at 5V, I used a programmable load to see how much current was available.  I was able to draw up to 2A from PP_HV1 before the power switch tripped.  Once the load was removed, the PP_HV1 eventually returned to 5V.

Is this behavior normal?  Is there a way to guarantee that PP_HV1 remains off when connected to standard USB ports?

Thank you,

Chris

  • Hi Chris,

    Do you have the ADCIN1 pin set to the "BP_NoWait" setting? This would ensure the TPS65987D loads from the SPI-Flash and not a default configuration. Additionally, are your Sink Capabilities set to only allow contracts greater than 5V? Per the USB PD spec, USB PD devices should be able to operate from 5V. If you have access to a PD analyzer, you can analyze the PD negotiation and ensure it is as expected.

    If this answers your question, PLEASE select This resolved my issue

    Thank you,
    Eric

  • Hi Eric,

    I believe we have it set for BP_NoWait. ADCIN1 = 15K PU to LDO_3V3. SPI_MISO = 10K PU to LDO_3V3.

    Thank you,

    Chris
  • Hi Chris,

    Is this still an open issue?

    Thank you,
    Eric
  • Hello,

    I have not heard back from you in a while.

    If I answered your question, PLEASE select This resolved my issue

    Thank you,
    Eric

  • Eric, the issue is still open. Here are customer's questions:

    1. Why does the TPS65987D sometimes provide 5V on the HV pins when connected to a non-PD capable USB 2.0 hub?
      1. The C_USB_P and C_USB_N pins are intentionally not connected because we do not support legacy 5V charging
      2. The HV switch is usually off when the device is first connected to the hub.  However, after about a minute, the switch will turn on and supply up to 2A of current.
      3. Sometimes the HV switch turns on immediately.  Sometimes it can take up to 5 minutes before the HV switch turns on.
    2. Here is what currently happens if a user plugs into a 5V USB source
    1. Battery Present
      1. The switch remains open (because there is >6V on the PP_HV1 pins from the battery).
    2. Battery Absent or Dead
    1. If powered from a standard USB hub, the switch usually begins in the off state.
    2. After a few seconds up to 5 minutes later, the switch closes and 5V appears to the system.
    3. Why does the TPS65987D close the switch when it couldn't get a contract?  Shouldn't it remain open?
    4. Why does the TPS65987D take a variable amount of time to close the switch?

    Thanks

    Viktorija

  • Viktorija,

    The TPS65987D does not differentiate between a non PD device or not. If Rd is presented by the device connected, the TPS65987D must provide 5V on VBUS per the Type-C Spec.
    A Type-C implicit contract would still be made regardless of C_USB_P/N connection.
  • Eric,
    My customer will get some scope shots, and send them to us. It may be early next week due to travel.
    They also believe there is a misunderstanding. Their design is for an Upstream Facing Port only. The behavior described above is for a Downstream Facing Port.
    Let me know what you think, please.
    Thanks
    Viktorija
  • Viktorija,

    The same concept would apply to an Upstream Facing Port. If they have a host EC on their platform, they could configure the Sink power path to close after they send an SRDY command (4CC command). More info on this can be found in our host interface TRM.
    The TPS65987D cannot pick and chose when to close the sink switch without the interaction of a host EC
    Please post a new thread when the scope data is available

    Thank you,
    Eric