• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 198 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.

TPS65988DK: schematic review

Devyn Lee
Prodigy 40 points
Part Number: TPS65988DK
Other Parts Discussed in Thread: TUSB1064, , HD3SS214, TPS65988, TPS65987DDK, TUSB564

Tool/software:

Hi 

we have a new project call RSW,  it is used for USB & DisplayPort switch for two host, we select TUSB1064 + TPS65988DK + hd3ss214 for its part function implementation. Here is correlative schematic, can you please help to review, thanks.

requires intro:

Two USB-TYPE C ports connect to two different computers, PD charge is no need.  TPS65988DK is used for DP alt mode, and some GPIOs for ctrl. TUSB1064 is for both USB & DP.

TUSB1064+TPS65988DK+hd3ss214.pdf

  • 0
    TI__Mastermind 28385 points

    Hi Devyn,

    I can review the TPS65988 portion of the schematic, please give me until the end of the week. Please provide responses to the questions to help with the process.

    What are your system requirements for the port? Are they DP Source, DFP, Power source only? A power contract is required, and can be limited to 5V,0A for a PD contract. Do you need any other voltages?

    Please submit a separate schematic review for with TUSB as the primary part if you have not already so their team can review it as well.

    Thanks and Regards,

    Chris.

  • 0 in reply to Christopher Lim1
    Prodigy 40 points

    Hi Chris.

    This is a device similar to a docking station,  so these ports are UFP, and we don't need PD, so no power demand. we only want it for DP alt mode controller.

    please note TUSB1064 + TPS65988DK + HD3SS214 are all required for review.

    Thanks!

    Devyn.

  • 0 in reply to Devyn Lee
    TI__Mastermind 28385 points

    Hi Devyn,

    As mentioned before, please submit a separate E2E ticket for the TUSB1064 + HD3SS214. I only support the TPS65987DDK and am only qualified to review the schematic for those parts. If you submit another E2E with the TUSB part as the primary part, it will go to the correct team for review. That team supports both parts.

    If I understand correctly, you have a 988 with two UFP ports? Are they both acting as DP Sink in this case? What pin assignments do you need to support? What DP roles? How are you controlling the TUSB1064 and HD3SS214 devices?

    To enter alt mode, it is required to first enter a power contract. In this case, it sounds like you probably want a 5V/0A contract which is the most basic power contract that does not draw power.

    How are you expecting to use each of the I2C ports? Controller, target, what is it controlling, what information is it expected to give?

    Thanks and Regards,

    Chris

  • 0 in reply to Christopher Lim1
    Prodigy 40 points

    Hi Chris:

    OK, got you now, I will submit another ticket for the TUSB1064 + HD3SS214 review. 

    Yes, the two ports in 988 are UFP ports, they are both acting as DP sink and also USB, the USB stream will go to a USB hub.  And DP stream will go to display. PIn assignments as the schematic show, please check whether it is ok. 

    TUSB1064 is working in GPIO mode, USB and DP are both fixed enable, and FLIP is configured by TPS65988. So we wish 988 can enter alt mode and handle the plug-in direction, then configure the FLIP correctly.

    We reserved the TUSB1064 I2C mode, in this mode,  we are going to use I2C3 (master) to control the 1064.

    Re HD3SS21 control, we want 988's GPIO12 to switch it, and also want GPIO13 to read the switch status, because we have a button which is also able to control it.

    For 988 control, there is no other controller in the docking, the host will be a dedicated computer which connect through USB TYPE-C, USB to a I2C bridge, then control 988 through I2C1(slave). The data stream as below:

    Meeting Computer --> TPS65988 & TUSB1064 --> USB stream to a USB HUB --> USB to I2C brideg --> I2C control TPS65988 (for switch HD3SS21)

    Re enter alt mode, how should we do for 5V/0A?

    Thanks!

    Devyn.

  • 0 in reply to Devyn Lee
    TI__Mastermind 28385 points

    Hi Devyn,

    My understanding of the DP spec is that pin assignments A, B and F are deprecated. Are you planning on using C, D and E? Check with the TUSB team, but if you force the USB and DP (CTL0, CTL1) gpios, it will force it into the multifunction (USB + DP) pin assignment, so pin assignments E and C would not be available either.

    Also, are you planning on switching between GPIO and I2C control for the 1064?

    How are you expecting the TPS65988 to control the TUSB1064 over I2C, please describe the behavior so we can confirm it is possible.

    Could you provide a spreadsheet that describes all of GPIOs being used on the TPS65988 and the expected behavior? The TPS65988 has a set of GPIO events so we need to confirm we can support the requirements. I know we have a cable flip/orientation GPIO, but I am not familiar with the GPIO requirements you are describing for GPIO12 and 13. 

    For GPIO12, what is it switching? I do not see it attached to anything.

    For GPIO13, you are expecting it to read in a value? Does it need to do anything, or is it just reporting if the pin is high or low?

    Devyn Lee said:
    Re enter alt mode, how should we do for 5V/0A?

    I'm not sure what you are asking here.

    The reason we need a voltage contract, is because prior to negotiating an alternate mode, it is required to negotiate a power contract. In this case, because you do not need to transmit power, we can just advertise and negotiate a 5V/0A contract so a power contract is negotiated but does not actually draw any power.

    In the GUI, we can configure both ports to only advertise 5V/0A contracts, and the PD controller will automatically negotiate those contracts if the host side supports USB-C PD.

    Thanks and Regards,

    Chris

  • 0 in reply to Christopher Lim1
    Prodigy 40 points

    Dear Chris:

    We are planning on using pin assignments - D, because USB+DP are must for us.

    We won't switch between GPIO and I2C control, the circuit is different, only one method is using. but reserve I2C mode for future, then the GPIO mode won't be used. But now, GPIO mode is our goal.

    When I2C mode, what we expect is that USB+DP are also must, 65988 set this configuration for default, then 659988 recognizes the TYPE-C orientation and automatically configures the FLIP of the 1064 via the I2C. The host (dedicated computer) can configure 65988 via I2C1 then 65988 configure 1064 via I2C3, configure such as EQ, please confirm if it is possible. 

    Here is the GPIOs expected behavior, please note as other TI teams advice I have add GPIO to control TUSB1064's CTL0/1 for enable DP/USB. please check if the GPIO configuration is ok.

    GPIO Net Function expect
    GPIO0 FLIP_PC recognizes the USB-C port1 (dedicated computer )orientation and configures the FLIP
    GPIO1 FLIP_MU recognizes the USB-C port2 (customer computer) orientation and configures the FLIP
    GPIO3 PC_HPD DP HPD
    GPIO4 MU_HPD DP HPD
    GPIO12 PDC_GPO_SW This signal will be sent to the clock input of the D trigger together with a button, and then the output of the D trigger will be to the DX_SEL of hd3ss214 to control the DP switch, so the GPIO needs to send a pulse signal every time after receiving the control from the HOST through I2C, expected behavior output L then H
    GPIO13 MUX_SW Receiving the switching signal from the output of the D flip-flop, the host reads this pin through I2C
    GPIO14 SW1_CTL1 output to TUSB1064#1, H for enable display port
    GPIO15 SW1_CTL0 output to TUSB1064#1, H for enable USB
    GPIO16 SW2_CTL1 output to TUSB1064#2, H for enable display port
    GPIO17 SW2_CTL0 output to TUSB1064#2, H for enable USB

    For the 5V/0A, does it need we design anything in the circuit? Or  just need configure it from the GUI configuration, I am asking it because I'm not sure what the 5V/0A circuit should be.

    Thanks!

    Devyn.

  • 0 in reply to Devyn Lee
    TI__Mastermind 28385 points

    Hi Devyn,

    Understood, yes, only one method should be used so I will focus on the GPIO implementation. If the EQ settings are fixed, then we can send fixed I2C writes to TUSB564 registers that can be set in the I2C controller events table and would be automatically sent by the PD controller on boot. There is also an "I2Cw" 4CC command that the host can send to "pass" I2C writes to the TUSB564. If the EQ settings are fixed, there should also be passives that can be set to configure EQ directly at the TUSB564.

    Thanks for the thorough GPIO information. All of them should be easily configured except GPIO12.

    For GPIO12: We have "4CC" commands to set the GPIO low and high individually that could be used, but we do not have a specific event that pulse the GPIO. Also, we do not have extensive timing on theses events, so if the pulse has very specific timing requirements, I do not know if the TPS65897 will be capable of meeting those timings and you may need to use something else to create this pulse. I would expect performance in the ms to 10s of ms but am not too sure.

    To create the pulse, first configure the GPIO to be output enabled and set the initial value to be high (if you want it default high). Then use the GPsl and GPsh 4cc commands to toggle the GPIO.

    Schematic Feedback.

    • For LDO1V8, we recommend a max of 6uF, you currently have 10uF
    • The VBUS node between the type-c receptacle and the PD controller has a max value of 10uF. You currently have a 22uF near the connector and a 1uF near the PD controller. We recommend 4.7uf or 2.2uF
    • Ensure that there are 3.3V pullup resistors somewhere on the I2C1 bus. I did not see them, but they may be on another sheet.
    • If you are using the HRESET pin, ground the pin using a 100k pulldown and a .01uF cap, else ground directly (0 ohm or direct connect
    • For the PPHV pins, use a weak pulldown to ground (100-k) instead of the direct connection to ground for both of them.
      • In addition, (this is very important), make sure that the powerpaths are never closed by doing the following:
        • Use a dead battery/ADCIN config that does not automatically enable the powerpaths. (should be good from what I saw in your schematic)
        • When configuring the project, configure the 5V/0A power paths for "Sink only, wait for SRDY". If you do sink only, when the contracts negotiate, the power path automatically closes. With "wait for SRDY", it does not close the power path until the SRDY command is sent by the host, and in this case, you should never send it to ensure the power path is never closed.

    Please share the updated schematics with the new GPIO connections when you get the chance.

    I'm not too concerned about these connections if you follow the TUSB team's recommendations, but it is good to be safe.

    Thanks and Regards,

    Chris

  • 0 in reply to Christopher Lim1
    Prodigy 40 points

    Hi Chris:

    For GPIO12, I think it should be ok, we don't need it output pulse automatically, it's not associated with any event, it's controlled by a host when we want to switch DP MUX (HD3SS214), so it should be ok if it can support output high and low, the host can handle the timing. And also, it's not necessay to meet any timing precisely, it is just used to simulate push-button event. How do you think?

    I follow up you commend and attached the updated schematic, please help to check, thank you very much for your time.

    TPS65988-For TI review.pdf

    Regards,

    Devyn

  • +1 in reply to Devyn Lee
    TI__Mastermind 28385 points

    Hi Devyn,

    Devyn Lee said:
    For GPIO12, I think it should be ok, we don't need it output pulse automatically, it's not associated with any event, it's controlled by a host when we want to switch DP MUX (HD3SS214), so it should be ok if it can support output high and low, the host can handle the timing. And also, it's not necessay to meet any timing precisely, it is just used to simulate push-button event. How do you think?

    As long as there are no strict timing requirements, I think it should be good! As mentioned before, you will need to configure the GPIO as an "Output Enabled Without Event" and use the GPsh and GPsl 4CC commands to assert and deassert the GPIOs from an I2C host. More information can be found in the device TRM.

    For the new schematic, I only reviewed the changes recommended (the fixes look good) and the new GPIO connections. Schematic looks good now.

    Thanks and Regards,

    Chris

  • 0 in reply to Christopher Lim1
    Prodigy 40 points

    Hi Chris:

    Ok, thank you very much for your time!