• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 33 subscribers
  • Views 507 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.

TPS65987DDJ: GPIO Event behavior on PR_SWAP

Ilya Tsunaev
Intellectual 305 points
Part Number: TPS65987DDJ


Hi,

I'm seeing an issue with the way one of the GPIO events work(Register 0x5C). Specifically "Source_Sink_Event_Port1" does not trigger as expected during PR_SWAP from being a Sink to becoming a Source, while the Status Register(0x1A [5]) properly updates to indicate that we are now a Source. If connecting directly to a Sink only device, this event is properly set. The issue is that if this IO is connected to control of the power source TPS65987DDJ fails to complete PR_SWAP as VBUS power is never turned on for sourcing.
Can you please confirm whether this is the expected behavior? If it is, what can be used as an alternative Event to control the power when acting as a Source?
Thanks,
Ilya
  • 0
    TI__Expert 6280 points

    Hi Ilya,

    Can you please send us the project file for the GPIO configuration? On our side we will try to reproduce this behavior.

    Thanks,

    Jacob

  • 0 in reply to Jacob Ontiveros
    Intellectual 305 points

    Hi Jacob,

    How can I share the project file privately?

    Thanks,

    Ilya

  • 0 in reply to Ilya Tsunaev
    TI__Expert 6280 points

    Hi Ilya,

    I requested to connect with you on e2e. I was able to test this and I was seeing the GPIO behaving as expected, I used one of the LED indicators on the EVM to confirm. I have the GPIO configured as below:

    Here is the PD log I took during the PR Swaps back and forth:

    I wonder if there is something else happening here, do you have the ability to take a PD log to make sure that the PR Swap is successful?

    Jacob

  • 0 in reply to Jacob Ontiveros
    TI__Expert 6280 points

    Ilya,

    I forgot to ask. Are you using the internal power paths of the PD controller to source and sink power?

    Jacob

  • 0 in reply to Jacob Ontiveros
    Intellectual 305 points

    Hi,

    I have shared the .pjt file privately. We are definitely succeeding in PR_SWAP as I can see that through the Mercury PD traffic analyzer.

    We are using internal sink and source paths HV1 and HV2 respectively.

    The way to reproduce the issue is that whenever negotiation succeeds do not supply VBUS on the HV2 path, and this results in "Port 1 Source Sink Event" never triggering. But in our case that trigger is the one that controls VBUS in the first place. So it's a chicken-n-egg problem here. I confirmed that if I enable VBUS on HV2 through different(manual) means the task completes and then the "Port 1 Source Sink Event" occurs.

    Thanks,

    Ilya

  • 0 in reply to Ilya Tsunaev
    TI__Expert 6280 points

    Hi Ilya,

    The PPHV1/2 are able to handle the switch over. 

    "But in our case that trigger is the one that controls VBUS in the first place:

    Do you have another path to VBUS present? If so that could be interfering with the timing. If the the old sink, new source does not provide VBUS there should be a PD hard reset, and the connection would break and then be reestablished. Could you send me the PD log?

    Jacob

  • 0 in reply to Jacob Ontiveros
    Intellectual 305 points

    Hi,

    It might be unfair for me to say "PR_SWAP" succeeds, it succeeds in sending the command to request but it never completes.

    To make sure we are on the same page I'll reword the issue and perhaps clarify some things:

    1) HV1 path is Sink path, HV2 is Source Path in our HW.

    2) The port partner is plugged in and it is a DRP that is acting as a Source(TPS65987DDJ Sink) (HV1 = 5V, HV2 = 0V )

    3) Our host sends a PR_SWAP to TPS65987DDJ to become a Source.

    4) HV1 is now 0V as the path is closed AND the old Source shut its source of after the USB-PD "PS Ready" message.

    5) HV2 is STILL 0V waiting for the GPIO to react to "Port 1 Source Sink Event".

    6) The TPS65987DDJ never sends "PS Ready"

    Here is a snippet of this bad case:

    Here is a snippet of a Success case where I manually apply VBUS on HV2 instead of waiting for "Port 1 Source Sink Event" to occur to drive out the GPIO that turns on VBUS on HV2.

    Thanks,

    Ilya

  • 0 in reply to Ilya Tsunaev
    TI__Expert 6280 points

    Hi Ilya,

    Are you gating the 5V supply for the PPHV2 based on the GPIO Source Sink Event? You should not gate the supply as you will run into timing issues. Is there a specific reason you would like to gate the supply?

    I reviewed your project and everything seems in order. I loaded your exact configuration on our EVM and saw that the PR Swaps were going through with several iterations. 

    Thanks,
    Jacob

  • 0 in reply to Jacob Ontiveros
    Intellectual 305 points

    Hi,

    This is the essence of the question. We are using that event to control the 5V supply our assumption was that this event would allow us to do everything we need.

    So going back to my original question:

    "Can you please confirm whether this is the expected behavior? If it is, what can be used as an alternative Event to control the power when acting as a Source?"

    Seems like this "bad" behavior is expected. Is there some other event we can use for the GPIO that gates the PPHV2 and works as desired for PR_SWAP as well non-DRP attachments?

    Thanks,

    Ilya

  • +1 in reply to Ilya Tsunaev
    TI__Expert 6280 points

    Hi Ilya,

    The Source Sink Event follows the Source or Sink switch. Before the Source switch is enabled the FW will check the voltage on PPHVx to determine that there is a valid voltage. The GPIO event will only change state when the switch is actually enabled and we are sourcing. 

    As a DRP port it is best to leave the 5V rail available since in practice any device can issue a PR Swap. You could base the control based on the PPHV1 state, with the PP1_SW_EVENT and have it inverted. So when the sink switch turns off during the first PSRDY it can drive the enable to your converter. You will also have to take into account the start up time of the converter. The maximum time per the spec is 550ms for the PS_RDY for the transition. 

    With all that being said, I still highly recommend leaving the supply available. 

    Jacob

  • 0 in reply to Jacob Ontiveros
    Intellectual 305 points

    Thank you Jacob.

    This helps resolve my question. I will investigate your proposal and if we hit any other issues I will open another question.