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 (Revisited)

Part Number: TPS25750
Other Parts Discussed in Thread: BQ25792, , USB-PD-CHG-EVM-01, BQ40Z50

Hi Chuck,

Some follow-up questions based on my previous thread:

1) Will the TPS change its RX_SINK_CAPS and TX_SOURCE_CAPS registers during operation? (I.e., do I have to read and then write to change the numValidPDOs, or could I just write based on a known configuration?)

2) The BQ25792 can handle faults of the battery either not wanting to discharge (empty) or not wanting to charge (full). Could you elaborate a little more on how this plays out? For example:

a) Does the TPS25750 learn what is going on and communicate this over USB-C to the attached device?

b) If the battery is later available, will the TPS or BQ figure this out and start charging/discharging, or would this require some other action? (Like unplugging and re-plugging in, or the micro sending a command to the TPS or BQ vis the TPS)

3) Did you create a post discussing TPS/BQ command interface/pass-through commands? (last post in the previous thread)

Thanks,

-Eric 

  • Eric,

    1.  Yes the RX_SINK_CAPS and TX_SOURCE_CAPS registers are automatically set via the configuration and you can write them based on your configuration

    2.  I will transfer this issue over the the BMS apps engineer to answer this question.

    3.  I have not yet because the GUI that has the firmware fix to make it work is not ready for release.  

    Regards,

    Chuck

  • Dear Eric,

    2) In the USB-PD-CHG-EVM-01 there is no ShipFet. As such, the battery is connected to the system through the body diode of the BATFET and nothing will stop it from discharging to the system. If you would like to add a ShipFet you can do so but you will need to control it through the previously said pass-through commands. As far as it relates to the BQ25792 outputting power through the TPS25750, the battery needs to meet the following conditions:

         The battery voltage is higher than VBAT_OTG rising threshold, and not trigger the VBAT_OVP protection.

         The VBUS is below V_VBUS_UVLO.

         The voltage at TS pin is within the range configured by BHOT and BCOLD register bits

     According to the BQ25792 datasheet, "At the end of the charging cycle, the charger automatically terminates when the charge current is below a pre-set limit (termination current) in the constant voltage phase."

    a) If the TPS25750 is configured as a sink, it will supply power to the BQ25792. If the TPS25750 is configured as a source, the battery will supply power through the BQ25792 and the TPS25750.

    b) The BQ25792 is configured by default to allow charging, provided all the conditions for charging are met as described in the datasheet. It will start discharging through the system as described in 2) automatically, and if the TPS25750 is configured as a source the BQ25792 will start OTG and supply power through the TPS25750.

    Thanks,

    Mike Emanuel

    Please click "Resolved" if this answered your question.

  • Mike: Sorry, I should have given more context: the battery is monitored by a BQ40Z50 with charge and discharge FETs, so it will open the FETs in the cases I'm talking about (charge FETs opened when the battery is full, discharge FETs opened when the battery is empty). How will the TPS25750 and BQ25792 behave if the battery FETs open because of something like this? Do I need to reconfigure the TPS25750 and/or BQ25792 when these (very normal) cases occur to avoid errors? 

    Chuck: Are you sure you mean the RX_SINK_CAPS (0x31), and not the TX_SINK_CAPS (0x33)? I'm querying the TPS25750 when loaded with the best configuration that I got from you (where charging works, and discharging works at 5V), and I see the following:

    RX_SOURCE_CAPS (0x30) 1D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    RX_SINK_CAPS (0x31) 1D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    TX_SOURCE_CAPS (0x32) 1F 03 A8 2A 2C 91 01 26 2C D1 02 00 2C B1 04 00 2C 41 06 00 F4 41 06 00 00 00 00 00 00 00 00 00 
    TX_SINK_CAPS (0x33) 1D 04 2C 91 01 10 2C D1 02 00 2C B1 04 00 2C 41 06 00 45 41 06 00 00 00 00 00 00 00 00 00 00 00 

    Thanks,

    -Eric

  • Chuck,

    Sorry to bother you, but I'm feeling like I'm missing something obvious. You mentioned "to issue GSkC to clear out the sink caps and SSrC to send the new source caps" for my changes to take effect. How do I do that via I2C commands? They don't have associated addresses, so I'm not understanding what these are / how I issue these.

    Thanks,

    -Eric

  • Hi Chuck,

    Problem one: RX_SINK_CAPS (0x31) already had zero valid profiles, so I decided to try adjusting TX_SINK_CAPS (0x33).

    Next problem: how to issue the commands. Reading further, if I understand this correctly, I'm supposed to be writing the commands as actual ASCII strings into register 0x08. I can read register 0x08 back, and either see zeros (it worked) or !CMD (it didn't work). So, I wrote:

    GSkC: 04 47 53 6B 43

    SSrC: 04 53 53 72 43

    Seem correct? (I read back zeros from the 0x08 register after each)

    Oddly enough, the registers then read like this (changes in bold):

    0x30 1D 04 2C 91 01 0A 2C D1 02 00 2C B1 04 00 45 41 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    0x31 1D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    0x32

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

    0x33

    1D 00 2C 91 01 10 2C D1 02 00 2C B1 04 00 2C 41 06 00 45 41 06 00 00 00 00 00 00 00 00 00 00 

    Now the RX_SOURCE_CAPS (0x030) register has some entries! (that look very similar to TX_SINK_CAPS!)

    When I tested the setup, charging is not disabled (still runs at 5V and up to 3A), discharging still only at 5V. 

    Not sure what else to try, I then cleared the valid entries in TX_SOURCE_CAPS (0x32), and reissued the GSkC and SSrC commands. I then saw:

    0x30 1D 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    0x31 1D 01 F4 91 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    0x32 1F 00 A8 2A 2C 91 01 26 2C D1 02 00 2C B1 04 00 2C 41 06 00 F4 41 06 00 00 00 00 00 00 00 00 
    0x32 1D 00 2C 91 01 10 2C D1 02 00 2C B1 04 00 2C 41 06 00 45 41 06 00 00 00 00 00 00 00 00 00 00 

    I don't see much difference in its behavior here: it still charges at 5V/3A, and still discharges at 5V. The one difference I do see is that my USB tester doesn't see it advertising other discharge voltages. 

    Thoughts? 

    Thanks,

    -Eric 

  • Hi Eric,

    The 4CC process you described seems correct.

    Chuck is out of office at the moment and will provide you with feedback once he returns.

    In the meantime, I would recommend taking a look at the Technical Reference Manual which will show the 4CC commands in more detail.

    Thank you,

    Hari

  • Ok, with my discharge configuration now working, I tried this process again:

    1. Modify register 0x32 (TX_SOURCE_CAPS) to not have any valid configurations (so setting the second byte to 0x00). Left otherwise unchanged.
    2. GSkC: Write "04 47 53 6B 43" (literally GSkC in ASCII) to register 0x08.
    3. SSrC: Write "04 53 53 72 43" (literally SSrC in ASCII) to register 0x08.

    This successfully disabled all of the discharge profiles other than the 5V one (up to 3A). Is this because the current is coming from the power supply, and not the BQ? Is there a way to disable this? (Or adjust the hardware to avoid this?)

    Thanks,

    -Eric

  • Eric,

    The Type C PD standard requires that a 5V PDO be provided if the device is configured as as DRP or a UFP, so there is no way to disable all sourcing unless you define the connection type as a SINK only.

    I need to think about any method that we could use to force to device into sink only mode.  This would resolve the issue that you are seeing.

    Regards,

    Chuck

  • Chuck,

    I'll try this on our own hardware soon, and let you know how it goes.

    Thanks,

    -Eric  

  • Eric,

    I will see what I can do testing this as well.

    Regards,

    Chuck

  • Eric,  Let's add this thread into our internal support issue.