• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 534 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TPS65988: All Samsung devices are not able to support PR_Swap request

Vitaliy Gurevich1
Intellectual 340 points
Part Number: TPS65988
Other Parts Discussed in Thread: TPD6S300

Hi,

I've trying to support the following sequence and not able to do with all Samsung phones?

The detailed description and HUB schematic are enclosed.

The PD communication messages for the Samsung phone are enclosed also.

  • The phone is connected to HUB J1 connector PD Port 1 (VBUS1)
  • The Charger is connected to HUB J2 connector PD Port 2 (VBUS2)
  • Manually send SWSr (Swap to Source=PR_Swap) command to PD Port 1 / PR_Swap to the phone
  • The phone is switched to Sink and start Charging
Thanks
Vitaliy

POC advance Port conf_Samsubg issue.pptPR_Swap Samsung S20+.xlsx

  • 0
    TI__Expert 7840 points

    Hello,

    I don't see PD contract in the trace attached. I can see Source cap messages but the port partner did not respond. Do you know from which side Source cap message is coming from (Phone or TPS65988)? 

    PN: its hard to analyse the trace in excel format. Please share the actual trace next time. 

    Thanks
    Prajith

  • 0 in reply to Prajith Cheerakkoda
    Intellectual 340 points

    Hi Prajith,

    1. I am using GRL-USB-PD-A1 dongle/parser and will enclose the actual traces for Samsung device (wrong behaviors) and Google device (good behaviors).

    2. I have enclosed the PD SW project for the registers setup review if needed.

    2. You can see on the attached slide of the Samsung S20 phone that the device is sending these messages (Vendor_Defined & Source_Capabilities) while insertion the phone to the HUB PD Port1 (J1/VBUS1), when the phone is Source.

    In the case of the Samsung phone - there are not PD messages running from PD to the phone while SWSr command sending to PD Port1 (phone). In the case of Google phone, everything is good and the phone is switched to Sink while sending SWSr command.

    Timestamp CH OS Power Data Cable Plug Type Mes ID Description
      6s 693ms 551us CC1 SOP' UFP or DFP Vendor_Defined 0 Discover Identity (Request) (SVID=FF00h)(Object Position=0)(Ver.1.0)
      6s 695ms 271us CC1 SOP' UFP or DFP Vendor_Defined 0 Discover Identity (Request) (SVID=FF00h)(Object Position=0)(Ver.1.0)
      6s 696ms 991us CC1 SOP' UFP or DFP Vendor_Defined 0 Discover Identity (Request) (SVID=FF00h)(Object Position=0)(Ver.1.0)
      6s 699ms 683us CC1 SOP Source DFP Source_Capabilities 0 [1]<Fixed> 5000[mV]/500[mA] (Dual-Role Power)(USB Suspend)(USB Communications)(Data-Role Data)(Peak Current=0) 
      6s 701ms 403us CC1 SOP Source DFP Source_Capabilities 0 [1]<Fixed> 5000[mV]/500[mA] (Dual-Role Power)(USB Suspend)(USB Communications)(Data-Role Data)(Peak Current=0) 
      6s 703ms 123us CC1 SOP Source DFP Source_Capabilities 0 [1]<Fixed> 5000[mV]/500[mA] (Dual-Role Power)(USB Suspend)(USB Communications)(Data-Role Data)(Peak Current=0) 

    Thanks

    Vitaliy

    Samsung phone Issue_PD traces & PD SW .zip

  • 0 in reply to Vitaliy Gurevich1
    Intellectual 340 points

    Hi Prajith,

    Yes. It seems like the phone is sending the Source_Capabilities message, but PD can't able to negotiate any. The phone is sending it in the loop during the ~ 8 seconds and then stopped - CC2 line is pulled low immediately after that.

    Regards

    Vitaliy

  • 0 in reply to Vitaliy Gurevich1
    TI__Expert 7840 points

    Hello,

    A quick test, could you remove one of the CC lines from plug side to 88DDH and check the behavior? Keep either CC1 or CC2 connected (Plug-88DDH). 

    If its still failing, please upload the FW state log. 

    Thanks
    Prajith 

  • 0 in reply to Prajith Cheerakkoda
    Intellectual 340 points

    Hi Prajith,

    1. I've cut the CC2 line between the J1 plug and PD controller input 88HD.

    Now, the Samsung device is able to negotiate the Source capability while insertion to PD Port1 and switched to SINK mode when the charger is plugged in into J2 (VBUS2) PD Port2.

    2. I am comparing the Samsung and Google PIXEL device's performance and see the differences on CC1 & CC2 signals behaviors while the device insertion in HUB and switching to from Sink/Source.

    Samsung device now keeps the CC2 &VCONN cut line active (device battery voltage) while insertion to the HUB, when the Google PIXEL device keeps CC2 LOW immediately after insertion.

    3. Could you please review the attached updated slides, PD FW logs, and GRL PD traces capturing for both Samsung & Pixel devices and explain why we need to cut the CC2 signal for Samsung when Pixel is working well in default implementation?

    4. Following your TPS95688EVM design, both CC1&CC2 are routed from the USB-C receptacles to the PD controller.

    5. Now, when I cut the CC2 signal how can I use VCONN voltage in my application?

    Thanks

    Vitaliy

    Samsung phone Issue_CC2_CUT___PD traces & FW state log.zip

  • 0 in reply to Vitaliy Gurevich1
    TI__Expert 7840 points

    Hello,

    VCONN power is required for the electronics inside EMCA cable. In your case, VCONN is not required as its a plug and no cable is involved. 

    EVM has Receptacle, thats why both CC lines are connected to the PD controller.

    In your case, the PD controller might be going to some other state as its seeing termination on both the ports, I'll review the logs and provide you my feedback soon. 

    Thanks
    Prajith

  • 0 in reply to Prajith Cheerakkoda
    Intellectual 340 points

    Hi Prajith,

    I've cut the CC2 line between the J1 plug and PD controller input 88HD.

    Could you please review PD FW logs and advise:

    1. I am comparing the Samsung and Google PIXEL device's performance and see the differences in CC1 & CC2 signals behaviors while the device insertion in HUB and switching to from Sink/Source.

    Samsung device now keeps the CC2 &VCONN cut line to PD as always active (device battery voltage) while insertion to the HUB, when the Google PIXEL device keeps CC2 LOW immediately after insertion. Why?

    2. Could you please review the attached updated slides, PD FW logs, and GRL PD traces capturing for both Samsung & Pixel devices and explain why we need to cut the CC2 signal for Samsung when Pixel is working well in default implementation?

    Thanks

    Vitaliy

  • 0 in reply to Vitaliy Gurevich1
    TI__Expert 7840 points

    Hello Vitaliy,

    PD controller is considering this connection (termination on both CC lines) as debug accessory mode. That's why its not responding to the source cap messages from phone. Please find the termination for debug accessory mode from type C spec below.

    From type C spec: "Two special termination combinations on the CC pins as seen by a Source are defined for directly attached Accessory Modes: Ra/Ra for Audio Adapter Accessory Mode (Appendix A) and Rd/Rd for Debug Accessory Mode (Appendix B)." 

    VCONN is required for powering electronics in EMCA cable. In your design the plug is directly mating w/ the receptacle in far-end (no cable involved). Hence, there is no need for VCONN power. The reason behind cutting the trace is that the receptacle expects termination on only one CC line. You are supposed to connect only the CC pin of connector to the PD controller. Keep the other pin (VCONN) floating. Please check pin out of Plug, cable and receptacle in type C spec. 

    BTW, the FW log you have uploaded is for passing case.  

    Thanks
    Prajith

  • 0 in reply to Prajith Cheerakkoda
    Intellectual 340 points

    Hi Prajith,

    Thanks for your explanation, it's clear.

    Could you please just clarify, why two phones (Samsung & Pixel) CC2=VCON are operating in difference way,

    when I cut CC2 line from the J1 plug to PD controller and DNP R26=0 Ohm RPD_G2 (TPD6S300) resistor for the dead battery support.

    Currently, the  CC2 line is totally floating from the J1 plug to PD CC2 input.

    1. I can see the differences in CC2 signal behavior while the device insertion into the HUB J1 PLUG and switching to from Sink/Source.

    Samsung device now keeps the CC2 &VCONN line in J1 PLUG as high (device battery voltage) while insertion to the HUB, when the Google PIXEL device keeps CC2 LOW immediately after insertion. Why?

    Please see the PD signal captures in my ppt presentation - slides 7&8.

    2. May I put Ra pull down resistor directly on the J1 plug in order to enable VCONN voltage for all attached devices according to the standard, if device is directly attached to J1 HUB plug without the active cable?

    May I use this VCONN voltage from the phone for some other targets inside my HUB and not for the biasing of the active cable that doesn't relevant in my case?

    Thanks

    Vitaliy

  • 0 in reply to Vitaliy Gurevich1
    Intellectual 340 points

    Hi Prajith,

    Could you please advise?

    Thanks

    Vitaliy

  • 0 in reply to Vitaliy Gurevich1
    TI__Expert 7840 points

    Hi Vitaliy,

    Regarding the difference b/w the Samsung and Pixel phone behavior, I've seen power adapters w/ plug presenting termination on both CC pins (Ex:Huawei mate 20 pro) for supporting proprietary charger protocol. So, the difference in behavior might be coming from there. Please check w/ the phone manufacturer for more details. 

    You can use the power from Vconn by placing Ra on the Vconn pin (max current is 600mA).

    Thanks

    Prajith