• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 348 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Basic 9V demonstration and current capability communication

Arthur Matteson1
Prodigy 20 points
Part Number: TPS65987D
Other Parts Discussed in Thread: BQ25890, , TPS65988

Hello,

We designed our own simple sink-only EVM for the TPS65987D and are trying to demonstrate 9V arbitration with a new RavPower RP-PC105 AC adapter, which claims to support up to 60W.  Our goal is to eventually use the TPS65987D in combination with a BQ25890 or a similar battery charging IC.  Our current project file (developed using the 6.1.1 software) as well as the test PCB's schematic are both attached to this post.

Our current progress is just being able to see the PP_HV1 line connect to VBUS as it should, but we can only get 5V despite using a proper USB-C cable with the PD3-enabled adapter.  We selected "Choose Highest Voltage" on the "Autonegotiate Sink" page and added a PDO for 9V.  The adapter seems to turn off VBUS temporarily (~1s) after the devices are plugged together with the cable, which may have only started after editing one of the many available options in the GUI.  Resetting the TPS65987D with our reset button causes it to boot correctly every other time, but the VBUS-off situation never repeats.  The cable orientation GPIO and some of the other GPIOs seem to be working, but we never get an indication of a sink PDO negotiation.

We have no load on PP_HV1 so far, and we are wondering if some existing current draw is required to negotiate a higher voltage, or if we can write the PDOs somehow to get to 9V right away (or at least after a short 5V period).  We went through numerous pages on this support forum and have read many related TI PDFs but were not able to find any obvious answers.  We are somewhat confused about how to write the sink PDOs, specifically how the "Operating" line relates to the "Minimum" and "Maximum" lines as well as the "Ask for Max" checkbox; we feel like we need more context for these.  The options are so numerous that setting this chip up is somewhat daunting, and if you can point us in the right direction regarding this issue, we would be grateful.

Our secondary concern is that when the user connects various supplies/cables to our battery-powered wireless hotspot in order to charge it, we need to limit the input current drawn by the BQ25890 based on the particular negotiated mode.  This could be anything as small as 0.5A all the way up to 3A, with many levels in-between due to BC1.2 and other proprietary methods.  It seems that this would be a very common need in designing such a product, and we cannot see any way around it unless the user is specifically forbidden from utilizing anything but USB-C-only hardware, or if we disable the other methods completely.  This topic was basically brought up in this thread:

https://e2e.ti.com/support/interface/f/138/t/853156

Is there any way to use a technique like those shown in the "Using I2C Master in TPS65987D and TPS65988 PD Controllers" document to send an I2C message based on the non-USB-C detected current limit, or are there any plans by TI to implement this in a future firmware update?  If so, this means we cannot use the BQ25890 unless we set up an additional microcontroller to read 0x3F and translate/transmit the data along, or give up on using BC1.2/proprietary methods and just limit the port draw to 0.5A if a USB-C cable is not found.  Or can the BQ25890 somehow still detect this limit itself with the D+/D- pins rerouted to it?  Our wish is that this all would be a bit more harmonized, but the USB standards seem to be evolving at a rapid pace and we understand it is difficult to make everything work together at once.

Thanks for any help you can provide!

- Arthur

Project.pjt

USB-C_Eval.pdf

  • 0
    TI__Expert 3135 points

    Hi Arthur,

    I have check your GUI confiuration, you may need change the sink type of 9V Sink PDO to Fixed sink, then you can get 9V sink. For the current limit of different type, we can't detect this information, and it is hard for source side to implement it, source just can set a current limit value for different PDO, it can't change.

    Best Regards,

    Kevin

    If this answers your question, Please click "This resolved my issue" button.

  • 0 in reply to Kevin-Cheng
    Prodigy 20 points

    Hi Kevin,

    This does in fact work, and the odd reset delay is gone, but none of our PDO LEDs seem to be indicating.  So in what circumstances would "Variable" and "Battery" modes switch to a higher voltage?  As we wondered earlier, what is the relationship between the "Operating" and "Minimum"/"Maximum" values?  Is this documented somewhere?  (The standards documents are notoriously difficult to read.)

    We think you misunderstood our comment about the current limit.  We are simply looking to know what to tell the BQ25890 to draw (into "IINLIM", "REG00<5:0>"), not actually have anything provide a real limit.  Obviously if the TPS65987D is detecting the BC1.2 modes itself, then it knows what the proper current limit is or it can easily (sort of, see below) be determined by a table.  Our idea is to load these into the BQ25890 so that the optimal current level is drawn to charge our battery.  We want to take advantage of what the source can provide but not overload it, and we want to support a wide variety of hardware (cables/adapters).  It seems that the only way is to add a separate microcontroller to accomplish this, by reading/interpreting register 0x3F, but we ask again, are there any plans by TI to add this functionality into the firmware for the TPS65987D?

    Getting more into specifics, and referring to "Table 3" in the BQ25890's datasheet, we see values from 0.5A (regular port) to 3.25A (BC1.2 Downstream Charging Port) with some included for proprietary methods.  If we try to match these up with the TPS65987D's documentation, we notice at least four changes.  First, "Divider 4" seems missing.  Second, a new 1.2V mode is added (supposedly for a 2A limit?).  Third, the TPS65987D's datasheet indicates a 2.4A level with "Divider 3" but "Table 3" says 1A.  Fourthly, the DCP mode is no longer 3.25A but just 1.5A; this appears to be a Type-C requirement.  Can you provide any clarity on these differences?

    Would connecting the BQ25890 directly to the D+/D- lines be a potential solution?  Could "IINLIM" be written (as in the "Using I2C Master..." document) then only if PDO negotiation was successful?  Are you aware of any negative side-effects of this method?

    Finally, we would like to bring to your attention what we feel are documentation issues.  One is the set of "Port 0 Source/Sink PDO Negotiated TT 1/2/3" in "slvae11.pdf" which are listed as inputs, when they should be listed as outputs - at least they are set as outputs through the GUI which makes the most sense.  Another is the title for "Table 5" in "slvae17a.pdf"; we believe this should say "0x3F" instead of "0x29".  One more relates to "Table 8/9" in "slva842.pdf" where "Object position" seems to take on the value of three bits where only one is available; if a zero value is reserved, then this bit would always have to be one, but we think something is missing here.

    Thanks,

    - Arthur

  • 0 in reply to Arthur Matteson1
    TI__Expert 3135 points

    Hi Arthur,

    The minimum value will limit the minimum capability of source, if source capability is less than the minimum value, then the PDO will not be negotiated.

    For PD negotiate, the source will boardcast the maximum current of each PDO, sink device can see this information, this is similar with the CDP means the source can provide 1.5A current.

    For BQ25890 question, i will loop the related engineer to answer it.

    thanks for pointing out our fault, i will inform our engineer to modify it.

    Best Regards,

    Kevin