• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 108 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.

TPS25751: Implementing BC1.2 with TPS25751D for USB-C data handling for external MCU

Arielle H
Prodigy 10 points

Part Number: TPS25751

Hello, I am creating a device that will source and sink power through a USBC port. The device will sink power to charge internal batteries with an external charging IC (MP2760) and will source power to the port to charge a phone from the battery. 

From my understanding, the TPS25751D has BC1.2 legacy support on the GPIO4/5 pins through tapping the D+/D- lines coming from the USBC connection. From the datasheet it seems as though I need a MUX that will route the D+/D- connection from the TPS25751D to the MCU once the BC1.2 has finished. I was wondering if this was necessary/how to do this (or if I could connect everything at once in parallel, which I am skeptical of). If I require a mux, I plan to use the TMUXHS221NKGR.

The thread in TPS25751EVM: GPIO Events to control USB2.0 Mux for BC1.2 compatibility is related in the sense where I am unsure how to implement the MUX if I do need it since I am assuming the MUX would need a constant voltage to route the D+/D- signals rather than a one off pulse like the thread is describing.  

The microcontroller (NRF5340) will communicate with the PD and charging ICs over I2C and the PD and charging ICs do not communicate, rather they have a shared power path. The microcontroller will need to send and receive data over the USB D+/D-.

I guess one option is to have the MCU in a HIZ state while the handshake occurs, but the legacy detection will only be necessary if the CC detection fails and I'm not too sure how difficult this will be to implement.

  • 0
    Prodigy 10 points

    This is another related thread where it is stated that there is no described event that occurs on the completion of the BC1.2 detection https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1590144/tps25751-bc1-2-support-and-dp-dm-handling-on-tps25751s. I'm not quite sure how to proceed from here - would the best solution be to forgo the BC1.2 detection all together?

  • 0 in reply to Arielle H
    TI__Guru 73871 points

    Hello,

    Arielle H said:
    From the datasheet it seems as though I need a MUX that will route the D+/D- connection from the TPS25751D to the MCU once the BC1.2 has finished.

    The intent of the mux would be to improve the signal integrity of the data path.  https://www.ti.com/lit/ds/symlink/tmuxhs221.pdf#page=7

    Arielle H said:
    I was wondering if this was necessary/how to do this (or if I could connect everything at once in parallel, which I am skeptical of). If I require a mux, I plan to use the TMUXHS221NKGR.

    I am not sure i can comment.  It will depend upon what data rates you want to support and how clean your traces are between the PD and the SOC/MCU.  In the diagram you show above you introduce a discontinuity when you split between the two devices and the mux would remove that discontinuity.

    You should use the Dp_Dm_MUX_Enable_Event to select (switch) the path from the PD to the MCU/SOC.  The description in the TRM is a little lacking, This will go high in the SDP/CDP cases but stay low in the DCP case.  You should not use DCP since you also need data.

    Arielle H said:
    The thread in TPS25751EVM: GPIO Events to control USB2.0 Mux for BC1.2 compatibility is related in the sense where I am unsure how to implement the MUX if I do need it since I am assuming the MUX would need a constant voltage to route the D+/D- signals rather than a one off pulse like the thread is describing.

    Please see above.  By constant voltage do you mean that the GPIO used to select the switch needs to remain high throughout the connection?  It will remain high.

    Is your system powered from VBUS or will another supply be available?  You can power the mux from LDO_3V3 which is derived from VBUS, see dead battery operation of the TPS25751.  https://www.ti.com/lit/ds/symlink/tps25751.pdf#page=30

    Arielle H said:
    This is another related thread where it is stated that there is no described event that occurs on the completion of the BC1.2 detection https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1590144/tps25751-bc1-2-support-and-dp-dm-handling-on-tps25751s. I'm not quite sure how to proceed from here - would the best solution be to forgo the BC1.2 detection all together?

    I believe that I was mistaken in the previous post.  I need to do some work, but it would appear that I missed and or incorrectly interpreted the event.  As previously stated the event Dp_Dm_MUX_Enable_Event would be the way to control the mux.

    I would highly recommend getting an EVM to validate your design.  Please be advised that there is a new updated part TPS25751A. https://www.ti.com/product/TPS25751A

    Arielle H said:
    I'm not quite sure how to proceed from here - would the best solution be to forgo the BC1.2 detection all together?

    If you do not have a hard requirement for BC1.2 then I would recommend just supporting the USBC-PD only.

    Regards,

    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 10 points

    Great! I will try to test the system with the evm board (for the tps25751D). I was hesitant to go for the tps25751A because the version available lacks the integrated FETs. 

    My system is powered from an external battery and VBUS is used to charge the battery or charge the phone. I am currently deriving power for the mux from the same LDO which powers the VIN_3V3 for the tps25751D. Would you recommend I power it off of the LDO_3V3? 

    Moreover, since the MCU I am using only supports USB2.0 I am limited by 480Mbps. If I were to exclusively support USBC-PD, is it correct that the charging current would be limited to 500mA and 5V if I were to encounter a legacy charger? 

    Much thanks.

  • 0 in reply to Arielle H
    TI__Guru 73871 points

    Hello,

    Arielle H said:
    Great! I will try to test the system with the evm board (for the tps25751D). I was hesitant to go for the tps25751A because the version available lacks the integrated FETs. 

    Thanks for highlighting that the 'D' package is missing.  I will work with the team to get that updated.

    Arielle H said:
    My system is powered from an external battery and VBUS is used to charge the battery or charge the phone. I am currently deriving power for the mux from the same LDO which powers the VIN_3V3 for the tps25751D. Would you recommend I power it off of the LDO_3V3?

    I would consider how you want the system to handle a dead-battery use case.  If you have mechanisms in place to prevent this then powering from the battery is ok.

    Arielle H said:
    Moreover, since the MCU I am using only supports USB2.0 I am limited by 480Mbps. If I were to exclusively support USBC-PD, is it correct that the charging current would be limited to 500mA and 5V if I were to encounter a legacy charger? 

    As a source, you can still advertise up to 3A over the CC pins.  The SDP would be limited to 900mA and the CDP 1.5A.  The far end may limit itself to draw a lower current.  I hope that is clear.

    Regards,

    Chris