• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 451 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.

Original question:

TPS65981: PD negotiation loop with Google Pixel

TPS65981: TPS65981: PD negotiation loop with Google Pixel

JERRY ZHANG
Prodigy 170 points
Part Number: TPS65981

I'm copying this description verbatim from https://e2e.ti.com/support/interface/f/138/t/750241?TPS65981-PD-negotiation-loop-with-Google-Pixel because my issue is incredibly identical to that one, which was closed without being resolved. PD logs on my side look the same as in the original post. I am using a total phase pd analyzer. 

------

I'm working on a design which is a UFP. When it is connected to a Samsung Galaxy S9 smart phone, I see the TPS65981 negotiate for the phone to be the power source based on my Sink PDO, as expected:

I get the Source_Capabilities, Request, Accept, and PS_RDY, all with GoodCRC.

However, when I connect the same board to a Google Pixel 3 phone, I get into a strange loop:

The phone sends out the Source_Capabilities message, then the TPS65981 responds with a GoodCRC, followed by a Request, followed by what appears to be a spurious GoodCRC? The phone never issues a GoodCRC, but it does attempt to send an Accept message, which is never acknowledged by the TPS65981. Since the Accept doesn't get a GoodCRC response, the phone starts generating Source_Capabilities messages and the whole process repeats for potentially thousands of messages. The fifth column is the message id; it keeps cycling between 0 and 1.

Eventually, somebody triggers a hard reset of the interface. I'm not sure if it's the phone or the TPS65981. After that, the negotiation works as expected:

It can take up to a minute for the phone to successfully establish a connection. Any ideas on what could be causing this?

I'm using version 6.1.1 of the Application Customization Tool.

  • 0
    Prodigy 170 points

    Since the most recent action in the attached post was requesting a log, I've attached a Total phase data center log of this interaction. It should include the messages sent as well as vbus and cc voltages. Let me know if you have any issues interpreting this.

  • 0
    Prodigy 170 points

    Nevermind i wasn't able to successfully attach a .tdc file, so i made a screenshot. You can see that the sink (TPS) sends a spurious GoodCRC message, which results in the source (Google pixel 3) never getting a GoodCRC for the accept message, and the vbus drops to 0 shortly after.

  • 0 in reply to JERRY ZHANG
    TI__Expert 8680 points

    Hi Jerry,

    Are you able to reproduce this issue 100%? Could you try it with a shorter cable? 

    I feel the spurious GoodCRC is coming from the phone with wrong value in Data/Power role field. I suspect this mainly due to two reasons

    1) The next message packet expected on the CC line after Request message from Sink is a GoodCRC from Source. I don't see a reason for Sink to misbehave here. 

    2) Src sent out an Accept message. This message is expected from Src only after sending GoodCRC in response to the Request message from Sink. 

    Capturing the logs using Ellisys analyzer can help to figure out the source of GoodCRC message from data rate.

    Thanks

    Prajith  

  • 0 in reply to Prajith Cheerakkoda
    TI__Expert 8680 points

    Hello Jerry,

    Please let me know if you have any updates on this issue. 

    Thanks
    Prajith

  • 0 in reply to Prajith Cheerakkoda
    Prodigy 170 points

    I don't see how the GoodCRC message could be coming from the phone. The analyzer says "Sink:UFP" which is definitely the role that the TPS65981 is in. Are you saying that the analyzer could be misassigning the source of this message?

    This reproduces 100% on every cable I've tried, including one that is only 3 inches in length. I've also tried several cables known to be well tested, such as the ones that come with the pixel phone. 

    The only PD analyzer i have is the total phase, I don't have an ellisys.

  • 0 in reply to JERRY ZHANG
    TI__Expert 8680 points

    Hi Jerry,

    DFP is supposed to send Accept message only after sending GoodCRC to the Request message. How do we interpret this behavior? 

    That's why I suspect that the GoodCRC message is from the DFP. Salea logic analog trace would also be helpful here. We can compare Saleae analog trace with PD trace captured in parallel to find out GoodCRC origin.   

    Thanks

    Prajith