• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 613 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.

TPS25750: Disabling Sinking or Sourcing

Eric Castle
Intellectual 710 points
Part Number: TPS25750
Other Parts Discussed in Thread: USB-PD-CHG-EVM-01, , BQ25792

Hello,

I've been working with the USB-PD-CHG-EVM-01 to show it working as a proof of concept for our battery. One thing that will be important for our application is to have the ability to separately disable sinking and/or sourcing (more sinking, but in error conditions we'll want to stop sourcing as well). 

I was hoping that the GPIO on the TPS25750 could be used for this, but slvuc05.pdf only outlines a few input functions (none of which seem applicable). Is it possible to do this over I2C? Or something else that I'm missing?

Thanks,

-Eric 

  • 0
    TI__Mastermind 32911 points

    Eric,

    You can disable sinking by setting the numValidPDOs bits to 0 in RX_SINK_CAPS Register (0x31) or sourcing by setting numValidPDOs to 0 in TX_SOURCE_CAPS Register (0x32).

    When you change one of these register, you will need to issue GSkC to clear out the sink caps and SSrC to send the new source caps.  

    By updating the specified registers and sending the matching command, you can disable sourcing or sinking via I2C.

    Regards,

    Chuck

  • 0 in reply to Chuck Branch
    Intellectual 710 points

    Hi Chuck,

    Thanks for the info. I tried looking at this today, and saw that the TX_SOURCE_CAPS register (0x32) was 31 bytes long. So...I guess to modify "numValidPDOs", I would need to read the entire register, and then write back the entire thing with just the "numValidPDOs" setting modified (and then issuing the SSrC). Correct? Or, could I simplify this by just storing the PDO configs in my micro, and just write the entire thing with a modified "numValidPDOs"? (do the PDOs remain constant once I've configured the device?)

    Below is me working to interpret the contents of this giant register (in case you notice if I did anything wrong, and to potentially help others).

    Thanks,

    -Eric

    Here's the values that I got for the TX_SOURCE_CAPS register (0x32), and my interpretation of them:

    1F 01 A8 2A 2C 91 01 26 2C D1 02 00 2C B1 04 00 F4 41 06 00 00 00 00 00 00 00 00 00 00 00 00 00  

    1F: 31 bytes follow

    01: Header (just PDO #1 valid PDO, I guess?)

    A8 2A (-> 0x2AA8): Power path configs (#1 uses the 5V; the rest use EXT1) 

    2C 91 01 26 (->0x2601912C) Is this 5V and 3A? I don't see anything in the documentation explaining the conversion of these values into Amps and Volts. Looks like 50 mV/bit, and 10 mA/bit?

    2C D1 02 00 (->0x0002D12C) 9V, 3A

    2C B1 04 00 (->0x0004B12C) 15V, 3A

    F4 41 06 00 (->0x000641F4) 20V, 5A

    00 00 00 00

    00 00 00 00

    00 00 00 00  

    Thanks,

    -Eric

  • 0 in reply to Eric Castle
    TI__Mastermind 32911 points

    Eric,

    You breakdown is spot on.  The one thing to note for the general audience is that they 0x1F is the number of bytes in the transaction which matchs the TX_SOURCE_CAPS register.

    Regards,

    Chuck

  • 0 in reply to Chuck Branch
    Intellectual 710 points

    Hi Chuck,

    With my application being a battery pack, it obviously can be fully charged or fully discharged, or have some sort of fault that prevents charging or discharging. 

    So, is sending I2C commands (like you described above) the intended way to handle these situations? 

    What would happen if the battery just didn't allow charging/discharging (FETs open)? I assume the IC can't detect this, and would still attempt to make USB-PD contracts that it couldn't keep?

    Thanks,

    -Eric 

  • 0 in reply to Eric Castle
    TI__Mastermind 32911 points

    Eric,

    The BQ25792 handles all of the faults that you have described.

    I am planning to write a post on what commands the TPS25750 writes in it's interface as well as how to pass commands through the TPS25750D to the BQ25792 in the next few weeks.

    Regrads,

    Chuck