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: HV1 switch does not close in dead battery condition

Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65987, , TPD6S300

Hello,

In my system, I use the USB-C connector as a Power Adapter input for the CPU board. This means that there is no battery in my system, I connect an USB-C charger and expect the 5V to be routed to my on board power supply which will supply the CPU. Finally this CPU will program the TPS65987 for extended features.

The TPS65987 has no Flash connected. I expect to program it though I2C when CPU has booted.

I use the BP_ECWait_Internal config:

What I have today:

* When I supply my CPU directly, and I program the TPS65987 with I2C, the PDO setup work properly. It does for example negotiate a 15V supply with the Power Adapter, and closes the HV1 power switch with no problem. The events (like sink PDO1 negotiated) do work also. If PDO are limited to 5V, it finished at 5V.

* Now If I only connect the Power Adapter to the USB-C (Nothing alive on the board yet, no voltage, no supply), the power adapter sets the VBUS to 5V, BUT the HV1 switch does not close, even if the LDO_3V3 is at right voltage, and the ADCIN1 is at 0.34V.

*I also tried to use the BP_ECWait_External, hoping that the GPIO16 would toggle (GPIO16 is supposed to enable an external switch instead of internal). But it does not work.

Does somebody have clues or proposal of tests to find out the problem ?

Thanks a lot.

  • Hello,

    I would recommend verifying your setup and how your PD controller is connected to your CPU. So you are able to see LDO_3V3 at the right voltage but the EC isn't receiving this signal?

    If you want to use the external power path, you will need to also make sure you have an external pull-down resistor on the GPIO16 pin. Can you verify you have this connected on your setup?

    Also, did you attach an image to this thread? I am unable to see it if you did, you may need to include a different file type.

    Thank you,

    Hari

  • Hello Hari,

    I checked your proposal.

    The CPU is connected to the controller through I2C. This link seems working properly as I can program the controller when the power is up and cpu running.

    In these conditions, the controller does the USB-C negotiations and I end up with for example 15V on the VBUS, and the HV1 switch is closed.

    Now when I only supply the board through USB-C, I see the LDO_3V3 at right voltage (of course the Vin_3V3 is not there as the board is not supplied yet). Here the CPU is also not running. The HV1 switch should close as the VBUS is at 5V, and I setup the ADCin1 voltage to act as "dead_battery" conditions.

    The external power path was just a trial. I don't want to do that. I expected that using this setting, I could see the GPIO16 toggling as if it would try to enable the external power switch. But it does not.
    In my application, the GPIO16 has a pull down already, and is used for other purpose as generic GPIO.

    The image I attached was the table 5 in chapter 8.4.1 showing the mode we select with ADCIN1=0.35V and SPI_MISO=0.

    Again, the main problem is: why does the HV1 power switch not close when the 5V is on VBUS. We are in the situation of, for example a tablet with a dead battery, where NO CPU can run, and the battery has to get power through the charger, which is connected to the HV1 switch. But in our case, the HV1 switch does not close...

    Many thanks for your support.

    Christophe.

  • Hi Christophe,

    Could you please verify that you have the proper bypass capacitors that are recommended in Table 27 of the TPS65987D datasheet for proper operation?

    Also, you mentioned that there is 5V on VBUS and that you want the PP_HV1 switch to close so you can sink power. Therefore, could you confirm that you are seeing this voltage on VBUS1 which is tied to PP_HV1, and not VBUS2 which is tied to PP_HV2?

    In the meantime, I will continue to look into this to see what else could be causing this issue.

    Thank you,

    Hari

  • Hello Hari,

    Sorry for the delay. We verified the bypass capacitors. They are compliant to the table.

    For the second part of your suggestion, we have implemented the chip similar to the FIGURE 38 (without TPD6S300 and without TUSB1046). CC lines are connected directly to the USB-C connector and USB data go to our controller, but are connected also to the BC1.2 inputs as recommended in Figure 56.

    The difference is that:

    * PPHV1 is connected to our system 5V (sink route), through a DC/DC supply to eventually convert the VBUS negotiated at 12V to 5V

    * PPHV2 is connected to the system 5V (source route), through a current limiter (to manage the max current our system can deliver to the USB load)

    Here you see that even on the FIGURE 38, both VBUS are connected together to USB-C connector, as in our implementation. So yes, we see the 5V voltage appearing on VBUS1 AND VBUS2.

    But in the scenario where our system is not supplied and we want to power it through the USB-C, we expect that the 5V, present on VBUS1&2, is propagated to the PPHV1 in order to supply our system. But the switch does not close.

    To be more clear, in these conditions, we see the 5V on VBUS 1&2, the Vin_3V3= 0V, the LDO_3V3=3.3V, the ADCin1=0.35V.

    The question is really: "what can be a good reason for the HV1 switch not to close" ?

    Thanks for your help.

    Christophe

  • Hi Christophe,

    Thank you for providing details on your setup. I will talk over your issue with my team and get back to you with a response by Friday. 

    Hari

  • Hi Christophe,

    It's strange that you're not seeing voltage on PPHV1. If you have SPI_MISO grounded, the right ADC_IN1 value and you're seeing voltage on VBUS, you should be able to see PPHV. Do you have anything unusual connected on PPHV that might be preventing the switch to close? Could you try to reproduce this on an EVM and tell me if you get the same result?

    Thank you,

    Hari