• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 743 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.

TPS65987D: Is the controller default suitable for source UFP?

Sam Dick
Prodigy 100 points
Part Number: TPS65987D
Other Parts Discussed in Thread: TPS2543, TPS65987, , TUSB422, TIDA-01620

Hello,

We have an application that's currently using a TPS2543 to enumerate a charge condition between a sinking host and a sourcing device. We're looking to add an IC between the existing circuit acting as the sourcing device that would allow use with USB-C. If the USB-C peripheral starts out as a sinking UFP and initiates a DR_SWAP command, will the TPS65987 be able to complete the sequence for the data role swap and allow the USB-C peripheral to act as a sinking DFP? Can this be done with a default configuration, and have the IC used standalone?

Regards,

Sam Dick

  • 0
    TI__Mastermind 28830 points

    Hello Sam,

    Yes, the TPS65987D is capable of this and is the device I would recommend.

    You use the application configuration tool to change the configuration of the device. It has templates that you can use as a starting point, one of them being a sinking DRP (UFP/DFP)

    The steps for ordering and using the EVM and GUI can be found on the EVM page https://www.ti.com/tool/TPS65987EVM 

    Also, the TPS65987D supports BC1.2 functionality ( https://www.ti.com/lit/an/slvae17a/slvae17a.pdf?&ts=1588960436102  ) so if you use this device, there is no need for the TPS2543

  • 0 in reply to Adam Mc Gaffin
    Prodigy 100 points

    Hi Adam,

    Thanks for the response. Unfortunately, the TPS2543 needs to remain as it's already built into the product. We're attempting to make an in-line adapter cable to support USB-C. That does bring up the question of what to do with the D+/D- pins on the TPS65987D. I would guess that since the USB-C device wouldn't try to enumerate via the full speed data bus it doesn't matter.

    My question was is the TPS65987D capable of performing the functions as delivered, without any additional configuration changes or programming? We'd ideally like to manufacture the cable without having an extra programming step, and our projected volumes wouldn't be high enough to request a special order run of pre-programmed ICs direct from TI.

    Regards,

    Sam Dick

  • 0 in reply to Sam Dick
    TI__Mastermind 28830 points

    Hi Sam,

    Then in this case, you do not need a device like the TPS65987D which is a full Type-C PD controller, and is much more than you need. Honestly, since you are only making a Type-A to Type-C cable, all you really need are some resistors.

    One of the biggest differences between Type-A and Type-C is that with Type-A, 5V is always presented on VBUS, regardless if there is a device connected or not. However, with Type-C, a device must first be connected before the charger can present the 5V on VBUS. This is done through resistors connected to the CC pins. The charger advertises a pullup resistor (Rp) while the sink advertises a pulldown resistor (Rd). When the two devices are connected, there will be a voltage drop on the CC channels which the source will detect, determine that a sink device has been connected, and assert the 5V on VBUS.

    For a Type-A to Type-C cable, there is a resistor within the cable that connects the CC pins to VBUS through an internal Rp. I've attached the Type-C spec, and you can see this cable diagram in section 3.5.1

    https://www.firefold.com/products/usb-c-cable?variant=17087961661513&msclkid=80ccbaee5db21a8414b5e4570d0bc62e&utm_source=bing&utm_medium=cpc&utm_campaign=BPA%20-%20Items%20-%20Firefold&utm_term=4579328493561376&utm_content=BPA%20Item%20-%20HOT%20ITEM%7CUSBC-USBA-6%7CFirefold%7CC%3A30

    7701.USB Type-C Specification Release 1.3.pdf

  • 0 in reply to Adam Mc Gaffin
    Prodigy 100 points

    Hi Adam,

    Thank you for the information, but I think we still need a controller. If we were to just use the Rd resistor the type C device would act as a sink, but it would default to being configured as UFP. From my understanding, if the type C device sends out the DR_SWAP message and doesn't get a GoodCRC it won't act as host. Would there be some alternate path for the type C device to recognize it needs to act as the data host?

    Regards,

    Sam Dick

  • 0 in reply to Sam Dick
    TI__Mastermind 28830 points

    Hi Sam,

    If you are wanting the connected Type-C device to act as both a sink and DFP, then yes, you will need PD controller within the cable to accept data role swaps etc...

    However, I still believe that the TPS65987D might be overkill for this type of application. All you need is a device to handle PD messaging on the CC channels. You can look into the TUSB422 to see if this might be a better fit. If not, the TPS65987D will still be a good choice

  • 0 in reply to Adam Mc Gaffin
    Prodigy 100 points

    Good morning Adam,

    The TUSB422 looks like it needs to have an external controller (TCPM) in order to send messages over the CC lines. If I'm reading it correctly, it will provide the physical and protocol layers, but the policy engine layer is external. I'm not sure if this would work for our application without additional complexity compared to the TPS65987D. Would the TUSB422 be able to generate the accept message in response to a DR_Swap generated by the type-C device without the policy engine? Is it able to retain register settings when power is removed?

    If we still need to stay with the TPS65987D, will it be capable of performing the functions as delivered, without any additional configuration changes or programming? 

    Regards,

    Sam Dick

  • 0 in reply to Sam Dick
    TI__Mastermind 28830 points

    Hi Sam,

    Yes you are correct, apologies. I do not support the TUSB422 so my understanding of the device is limited. I found this reference design that is similar to what I think you are trying to accomplish, except a DP port a Type-A port. They use a MSP430 on the design which makes me believe you must use a controller with the TUSB422.

    https://www.ti.com/tool/TIDA-01620

    You can use the TPS65987D for this application. There are default configurations that you can use outline in Table 7 of the datasheet, but I would recommend that you use an external flash and create a custom configuration using the application GUI. I say this because there is no default configuration that allows for DRP functionality, and since the TPS2543 is supplying VBUS, you should set the source capabilities to 1.5A instead of 3A. Also, similar to the TIDA-01620 reference design, you will need to place a MUX on this system for the polarity of the cable, and you can use GPIO's from the TPS65987D to control the MUX

  • 0 in reply to Adam Mc Gaffin
    Prodigy 100 points

    Good morning Adam,

    Thank you for the additional information. The only thing I'm confused about is the need for a mux. Doesn't the TPS65987D have provisions for cable orientation built in?

    Regards,

    Sam Dick

  • 0 in reply to Sam Dick
    TI__Mastermind 28830 points

    Hi Sam,

    No it does not. You will need to use an external mux to connect the super speed lines to that change which lanes are connected depending on the orientation of the Type-C cable. The TPS65987D can control an external mux through the use of GPIO events

  • 0 in reply to Adam Mc Gaffin
    Prodigy 100 points

    Hi Adam,

    I think that's where I was confused. We're only looking to use USB 2.0 high speed, so the super speed lines aren't going to be used. Just to double check, am I correct that we won't need the mux for that?

    Regards,

    Sam Dick

  • 0 in reply to Sam Dick
    TI__Mastermind 28830 points

    No you will not need a mux for the USB2.0 lines. You will not need to connect these to the TPS65987D either since the BC1.2 negotiation is still handled by the TPS2543