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: Recommended TPS65987D GPIO configuration to drive the BQ25713's OtG pin.

Part Number: TPS65987D
Other Parts Discussed in Thread: BQ25713, , BQ25703A, BQ25703

We have the TPS65987D mated with a BQ25713 such that the Type-C/PD port is both a [heavy up to 20V, 3A] sink and lightweight source (5V@1.5A) exploiting the BQ25713's bidirectional power capability.  The TPS65987D has its GPIO1 connected to such BQ25713 pin.

We are wondering if TI has an actual application example of this being done (with the BQ25713 or any of its close BQ257xx relatives) and in particular what is the configuration done on the TPS65987D GPIO that drives such OtG pin.

This is how we believe such GPIO1 ought to be configured:

This case is corollary to https://e2e.ti.com/support/interface/f/138/t/927370  (TPS65987D: Port 0 Source/Sink GPIO event unexpected behavior) where issues have been uncovered with such configuration and particularly when another port (GPIO20) is configured similarly but with opposite polarity for use in another circuit portion in our design.

Such GPIO20 is configured as follows:

Thanks so much,

Georg A. Mussenden

  • Hi George,

    Using the Source Sink GPIO event should accomplish what you are wanting for the OTG pin. We do not currently have a reference design posted showing the connections between a PD controller and BQ device, but we have plans of adding one sometime this quarter 

  • Thanks so much Adam!

    Might be wise for you to get in touch with https://e2e.ti.com/members/6063892 who's troubleshooting the aforementioned e2e.ti.com/.../927370.

    Please quickly let me know when a reference design between the TPS65987D and a BQ257xx has been defined!

    Have a Great WeekEnd!

    Georg A. Mussenden

    1105

  • Hi Adam, Kedar:

    This last Friday (Aug. 21) I discovered something interesting....

    It seems like the TPS65987D has a mechanism in which it detects the suitable presence of 5V at the input of its Outbound VBus (PP_HV2 in our case) prior to offering Source capabilities (i.e. offering the Ip current on the CC wire). If such 5V voltage is not found, Ip won't be presented.

    This of course not only affects the Ip generation itself but the Source/Sink mechanism configured on GPIO1 as because there's no Ip generated due to the '25713 not being in OtG mode (as to generate 5V) no reliable decision can be made as to the TPS65987D being in Source mode or not - resulting in a chicken vs. egg problem. Note that I'm not complaining, this is actually a wise approach on the TPS65987D's logic as it would be foolish to offer source capability if the source to drive out into VBus is not present!

    I inadvertently discovered this whilst running TEST.PD.PHY.ALL.05 Receiver Interference Rejection (2-Tone method) and TEST.PD.PHY.ALL.05 Receiver Interference Rejection (AWS method) compliance tests in which the Source mode tests always failed due to lack of source negotiation of our product when it was supposed to do sourcing capability during the tests. When I connected PP_HV2 to an always present sourve of 5V, such problem went away.

    This makes me believe that when nothing is attached on a DRP port controlled by the TPS65987D (and is desired to be able to connect to a sink device), the BQ25713 needs to be configured and enabled in OtG mode such that the TPS65987D sees such 5V and then it be willing to offer Ip (during the DRP "dance").

    I'd consequently reckon that my GPIO1 configuration needs to be slightly (and dynamically) modified such that it has a Pull-Up resistor when the system wants to host sink devices (typically when the system is in an On & Ready state) and have a Pull-Down (or set to a hard Low) when the system doesn't want to host sink devices (typically when the system is in an Off state and is desired to save power by the BQ25713 not running).

    Please confirm with your peers if my configuration proposal seems right and if TI might have a draft of an app. note since you claimed that TI will have an app circuit marrying the TPS6598X and BQ257XX devices sometime this quarter. Such app. note might further delineate timing subtleties we should abide to.

    Most Grateful,

    Georg A. Mussenden

  • Georg Mussenden said:
    This makes me believe that when nothing is attached on a DRP port controlled by the TPS65987D (and is desired to be able to connect to a sink device), the BQ25713 needs to be configured and enabled in OtG mode such that the TPS65987D sees such 5V and then it be willing to offer Ip (during the DRP "dance").

    Yes I think this is the correct assumption. This is how the reference design is enabled. That when the device is first powered up, and there is nothing connected to the Type-C port, the BQ outputs 5V. You can referene the following app note on an example for what should be written to a BQ. The app note connects to the BQ25703A

    https://www.ti.com/lit/pdf/slvae18  

  • Thanks so much Adam for confirming that the TPS65987D requires 5V present at PP_HV2 as for it to offer Ip at the CC line!

    I did look at the slvae18 app note you suggested and albeit it has a lot of detail on initializing the BQ25703 for OtG (which I know how to do and we use a supervisory micro to do so instead of using the TPS65987D) the part it's missing is the TPS65987D GPIO itself which is very faintly mentioned on page 8 of such document but its configuration is not shown.

    I gather such GPIO configuration shall look like this:

    Which differs from my original suggestion in that now I enable the Pull-Up instead of the Pull-Down resistor so OtG mode is the default if nothing's attached.  However please check if the Initial Value shall be 0x0 or 0x1.  I have 0x0 as I think it's safer to have the BQ25713 initially as a sink and once things settle from Reset normal operation follows, but please correct me if I'm wrong!

    I'll let you know when our SW folks have implemented this stuff and if it works I close the case.

    Most Grateful,

    Georg A. Mussenden

  • Hi Georg,

    Yes I think that GPIO configuration looks correct.