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: UCSI Command "SWSr" & "SWSk" failure

Part Number: TPS65987D

Hi, everyone,


About UCSI 4CC commands "SWSr" & "SWSk".

We noticed After we change 0x29 register

29 04 02 44 19 C7
-> NG. "SWSr" & "SWSk" won't work.

29 04 52 44 19 C7
-> OK. "SWSr" & "SWSk" work properly.


These differences are ProcessSwaptoSink / ProcessSwaptoSource
and when these bit becomes 0, "SWSr" & "SWSk" commands are NG.


But "TPS65987DDH Host Interface Technical Reference Manual" says nothing about this settings.
(It doesn't says "SWSk & SWSr are rejected".)

Does these phenomena coincide with specification of TPS65987D?


Thank you.


Best Regards,

  • And also, could you examine about this problem by TPS65987D-90EVM?

    [Procedure]
    - Attach AC adaptor & PD adaptor to EVM.
    - Send "SWSr" command from Aardvark.
    Then, you can see PR_Swap made & CCx lines toggling.
    - Send 0x29 write command
    29 04 02 44 19 C7
    - Again, send "SWSr" command from Aarvark.
    Then, you cannnot see PR_Swap.

    [Note]
    If you send 0x29 write command
    29 04 52 44 19 C7
    , then you can see PR_Swap by "SWSr" command.

    # We've sent Our project file to Eric-san before.


    Thank you.


    Best Regards,
  • Hi Maurice,

    Thanks for reaching out to us.

    If you look at the register values written in both the case then the only difference is the first byte which is 0x52 when PR_Swap is and 0x02 when the PR_Swap is not working.

    Now if you look at Table 3.14 of the "TPS65987DDH and TPS65988DH Host Interface Technical Reference Manual" then you find that writing 0x52 to the first byte if this register enables the "ProcessSwapToSource" and "ProcessSwapToSink" features. This allows the PD controller to accept PR_Swap messages as the PD controller will process the incoming PR_Swap requests. However, if the highlighted bits are not set (when 0x02 is written to this register) then the PD controller doesn't automatically accept the PR_Swap requests and you see that it not working.

    Please click "This resolves my issue" if I was able to answer your question.

    Thanks,

    Rahul

  • Hi, Rahul-san,


    Yes, of course we confirmed "ProcessSwapToSource & "ProcessSwapToSink".


    But

    (1) We understand ProcessSwapToSink & ProcessSwapToSource are bits
    that can set response of TPS65987D when receiving PR_Swap,
    But TPS65987D stop making PR_Swap itself by "Write 29 04 02 44 19 C7" command.
    Why is this?
    This is different from spec. of ProcessSwapToSource/Sink.


    (2) And also, "Write 29 04 02 44 19 C7" command is needed according to UCSI specification.
    If 4CC command "SWSr" & "SWSk" won't work by this command,
    we cannot pass logo test (HLK).


    So we think you need to revise base firmware.


    ==============================

    And about UCSI, refer this website.

    www.intel.com/.../usb-type-c-ucsi-spec.pdf

    Table 4-22: SET_PDR Command on page 34 tells you bit assignment of command.
    If bit 2 of offset 23 is to be 0,
    swap request from port partner need to be rejected.


    And also, there's example of UCSI command
    docs.microsoft.com/.../ucsi

    Set PDR
    Provider: UcsiControl.exe Send 0 81000B
    Consumer: UcsiControl.exe Send 0 101000B
    Accept: UcsiControl.exe Send 0 201000B

    And if command to be provider is execurted,
    both SwapToSource & Reject are needed.

    Note that Offset 23: 000 is prohibited,
    so only Reject command doesn't exist.



    Thank you.


    Best Regards,
  • Hi Maurice,

    To set power direction as per the UCSI spec, you will have to send SET_PDR command to 87D PD controller. Details is explained in page 169 of FW HI TRM document, link below.

    www.ti.com/.../slvubh2b.pdf

    Regards,
    Atiq
  • Hi, Atiq-san,


    We tried your WA idea, but it won't work.



    <Validation environment>

    Attach AC adaptor & PD adaptor to TPS65987D-90EVM.
    Measure I2C & PD negotiation with analyzer.



    <Procedure>

    Initiate swap to source by Set_PDR (Atiq-san's WA)
    (1) execute UCSI command 3 times.
    Write 09 08 0B 00 81 00 00 00 00
    and next,
    Write 08 04 55 43 53 49

    -> Only first 1 time, TPS65987D makes PR_Swap.
    (After 2nd time, TPS65987D won't make PR_Swap)


    #About UCSI swap to sink command, you can see the similar phenomenon.


    Thank you.


    Best Regards,
  • Hi, Atiq-san,



    We tried 4CC "SWSr" / "SWSk" command by using TPS65987D-90EVM again.



    <Validation environment>
    Attach AC adaptor & PD adaptor to TPS65987D-90EVM.
    Measure I2C & PD negotiation with analyzer.



    <Procedure> "SWSr" command

    (1) Execute "SWSr" command (Write 08 04 53 57 53 72)
    ->TPS65987D makes PR_Swap.

    (2) Write 29 04 02 44 19 C7
    -> ProcessSwapToSource becomes 0.

    (3) Execute "SWSr" command 3 times.
    -> TPS65987D won't make PR_Swap.


    #About "SWSk" & "ProcessSwapToSink", you can see the similar phenomenon.

    # And also, I sent I2C / PD negotiation log files to Yone-san & Rahul-san.
    For detail, please refer these files.


    Anyway, As I've told Yone-san before,
    In datasheet of TPS65987D, it doesn't say
    TPS65987D won't make PR_Swap by 4CC command "SWSr" & "SWSk" by ProcessSwapToSink/Source=0.

    These bits determine whether TPS65987D accepts PR_Swap or not,
    and they don't determine whether TPS65987D makes PR_Swap or not.

    In other words, TPS65987D works wrong with specification datasheet.

    After all, base firmware must be revised as the countermeasure
    so that TPS65987D makes PR_Swap even if ProcessSwapToSource / Sink = 0.


    Thank you.


    Best Regards,
  • Hi Maurice,

    It's an expected behaviour because say to start with 87D was in sink role and you issue the UCSI command then the 87D will go to Source role. Now, second time onwards the 87D is already in Source mode so the UCSI command will have no effect and same applies if the 87D starts as a Sink.

    You need to change the parameter after every PR Swap to ensure it goes from sink to source to sink ....

    Thanks,
    Rahul
  • Hi, Rahul-san,

    Thank you for your reply.

    >It's an expected behaviour because say to start with 87D was in sink role

    >and you issue the UCSI command then the 87D will go to Source role.

    >Now, second time onwards the 87D is already in Source mode

    No.

    First time 87D makes PR_Swap by "SWSr" command, but far-end device rejected.

    So 87D is still Sink when we command "SWSr" again.

    Please confirm attached files.

    And also, we think it's strange

    87D won't make PR_Swap gain, whether 87D is Source or Sink.

    Thank you.

    Best Regards,

  • # Sorry, let me post again, because attached files won't be browsed properly...

    Hi, Rahul-san,

    Thank you for your reply.

    >It's an expected behaviour because say to start with 87D was in sink role

    >and you issue the UCSI command then the 87D will go to Source role.

    >Now, second time onwards the 87D is already in Source mode

    No.

    First time 87D makes PR_Swap by "SWSr" command, but far-end device rejected.

    So 87D is still Sink when we command "SWSr" again.

    Please confirm attached files.

    And also, we think it's strange

    87D won't make PR_Swap gain, whether 87D is Source or Sink.

    Thank you.

    Best Regards,

  • Hi Maurice,

    We would like to understand your exact test sequence. Please provide the details of tests, expected results, and failures you're seeing.

    All the UCSI functionalities could be implemented using the UCSI specific 4CC commands. We, therefore, don't understand why you're trying to modify the content of 0x29 register and explicitly executing SWSr & SWSk 4CC commands.

    Can you implement the required UCSI functionality using UCSI 4CC command (and not SWsk & Swsr commands) and let us know if you see any gaps/issues?

    Please provide us the test sequence and failure results when you that UCSI commands are not doing what you expect to do. For example failure of power role swaps after UCSI commands.

    Thanks,
    Rahul

  • Hi, Rahul-san,


    > We would like to understand you exact test sequence
    > and want to know UCSI and 4CC test sequence seperately.

    I'll explain problem & procedure again...

    First, Case: UCSI


    <Problem>
    87D won't make PR_Swap when ProcessSwapToSink / ProcessSwapToSource.

    As I've told Yone-san before,
     In datasheet of 987D, it doesn't say
    987D won't make PR_Swap by ProcessSwapToSink/Source=0.

     These bits determine whether TPS65987D accepts PR_Swap or not,
     and they don't determine whether TPS65987D makes PR_Swap or not.

     In other words, TPS65987D obviously works wrong with specification datasheet.


    <Validation environment>
     Attach AC adaptor & PD adaptor to TPS65987D-90EVM.
     Measure I2C & PD negotiation with analyzer.


     <Procedure>

     Initiate swap to source by Set_PDR (Atiq-san's WA)
     (1) execute UCSI command 3 times.
     Write 09 08 0B 00 81 00 00 00 00
     and next,
     Write 08 04 55 43 53 49

     -> Only first 1 time, TPS65987D makes PR_Swap.
     (After 2nd time, TPS65987D won't make PR_Swap)

    Why is this?

     

    I've said again and again, In datasheet of 987D, it doesn't say
    987D
    won't make PR_Swap by ProcessSwapToSink/Source=0.

     These bits determine whether TPS65987D accepts PR_Swap or not,
     and they don't determine whether TPS65987D makes PR_Swap or not.

     In other words, TPS65987D obviously works wrong with specification datasheet.

    For detail, please confirm the attached file.

    Best Regards,

    TPS65987DEVM_FW04_V4.03_SetPDR_SwapToSource_3times.zip

  • Hi, Rahul-san,


    > We would like to understand you exact test sequence
    > and want to know UCSI and 4CC test sequence seperately.

    Next, I'll explain the procedure about 4CC "SWSr" test.

     

    <Problem> (#same with the case of UCSI)
    87D won't make PR_Swap when ProcessSwapToSink / ProcessSwapToSource.

    As I've told Yone-san before,
     In datasheet of 987D, it doesn't say
    987D won't make PR_Swap by ProcessSwapToSink/Source=0.

     These bits determine whether TPS65987D accepts PR_Swap or not,
     and they don't determine whether TPS65987D makes PR_Swap or not.

     In other words, TPS65987D obviously works wrong with specification datasheet.


    <Validation environment>
     Attach AC adaptor & PD adaptor to TPS65987D-90EVM.
     Measure I2C & PD negotiation with analyzer.


     <Procedure>

     (1) Execute "SWSr" command (Write 08 04 53 57 53 72)
    ->TPS65987D makes PR_Swap.

    (2) Write 29 04 02 44 19 C7
    -> ProcessSwapToSource becomes 0.

    (3) Execute "SWSr" command 3 times.
    -> TPS65987D won't make PR_Swap.

    For detail, please confirm the attached log file.

     

    Why PR_Swap won't be made?

     In datasheet of 987D, it doesn't say
    987D won't make PR_Swap by ProcessSwapToSink/Source=0.

     These bits determine whether TPS65987D accepts PR_Swap or not,
     and they don't determine whether TPS65987D makes PR_Swap or not.

     In other words, TPS65987D obviously works wrong with specification datasheet.

    TPS65987DEVM_FW04_V4.03_SWSr_3times.zip

    Best Regards,

  • Hi Maurice,

    I got the I2C and PD logs from Satoshi San and after reviewing this we found that this is an expected behaviour.

    Explanation:
    Our PD controller issues a PR Swap after getting the SET_PDR UCSI command and this PR Swap command is rejected from the port partner (other device connected to the laptop). Upon receiving this Rejection our PD controller knows that the port partner doesn't support PR Swap feature and therefore doesn't sent PR Swap command even when SET_PDR UCSI command is received as the PD controller knows that the port partner doesn't support PR swap.

    Please let us know what is your expectation when SET_PDR command is issued 2nd time onwards.


    Thanks,
    Rahul