• State
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Subscribers 67 subscribers
  • Views 227 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: Close internal PowerPath faster when alternate power source removed

Jonny Hall
Prodigy 65 points
Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65987,

We have a design that can be powered from either USB-C or a barrel jack. We want to support seamless switching / failover from barrel jack to USB-C power, but don't have space on the board for an additional power ORing / or ideal diode controller. The barrel jack input protection circuitry has a power good output, which is routed to pin GPIO20 and configured as "barrel jack detect event" on the TPS65987 . The TPS65987 uses internal powerpath PP1 for the sink profile. In the configuration tool, under "port control", the "sink control bit" is set.

With this configuration, the board works fine with either USB-C or barrel jack power individually. When both are inserted, the TPS65987D correctly detects the barrel jack PGOOD signal and opens its internal powerpath, and the board can seamlessly switch over from USB-C to barrel jack power. However, if both power sources are present, and the barrel jack is removed, it appears that the powerpath is not closed fast enough to maintain board power.

- The barrel jack power source is nominally 12V, power failure detection threshold is around 10V, and the board can operate down to 5V. We support USB-C PD profiles between 9V-15V. Given the capacitance board, it takes around 1ms for the voltage on the input rail to fall from 10V to 5V and other regulators to start dropping out, resetting the board.


- We see that when the board is powered from a barrel jack, and then a USB-C PD source is connected, a valid profile is correctly negotiated, the source provides the expected VBUS voltage, and the TPS65987 correctly keeps its internal powerpath open. (If the "sink control bit" is not set, the powerpath is immediately closed and the USB-C source can back-feed the barrel jack supply -- this is not desirable behavior; we want to prioritize operation from the barrel jack and failover to USB-C only when barrel jack is not present, allowing for example users to use a USB-C battery bank as a backup supply)


- In the above state, when the barrel jack is unplugged, the PGOOD signal is deasserted at the expected voltage level. However, the TPS65987D takes too long to respond to the event and close the powerpath. This needs to happen within the ~1ms window before the voltage decays to the point that other rails start dropping out, but it seems to take several milliseconds minimum and the board generally loses power, resets, and then reboots on USB-C power.


- We have already set the "Soft Start Slew Rate" setting under "Port Configuration" to the maximum, 3.39V/ms.

Is there anything we're missing in the configuration to either (a) disable soft-start entirely, (b) make the TPS65987D respond to the barrel jack detect even faster, or (c) otherwise increase the speed of failover to USB-C power? Our board is quite space-constrained, so it's unlikely that we'd be able to add an independent power ORing controller, or substantial additional capacitance to hold up the system rails for longer, and we were hoping to achieve this with just the functionality of the TPS65987D.

  • 0
    TI__Genius 14955 points

    Hi Jonny,

    Thanks for reaching out on E2E!

    Can you please provide me with PD log of what you are describing above?

    Thank you,

    Kevin

  • 0 in reply to Kevin Kosta
    Prodigy 65 points

    Hi Kevin, I have a PD capture from using the TotalPhase USB Power Delivery Analyzer that I'll try to figure out how to send to you, though I'm not sure that it will prove to be very helpful.  Basically, when the USB-C source is connected to our board, it correctly negotiates a valid profile and the board turns on.  When the barrel jack is also connected, the only difference is that our board attempts a power role swap, which the source denies (NOTE: We may want to disable this setting in our configuration, but this is NOT the root cause of our current issue -- the source denies the swap and continues providing power as expected).  When the barrel jack is removed, the board (and TPS65987D) reset and then our board re-negotiates a valid PD profile and turns on again.

    What I think will be potentially more helpful are the below scope captures.  In these captures, trace 1 (red) is the system's main power rail (V_SYS), provided by either the barrel jack or USB-C powerpath (downstream of the TPS65987D powerpath).  Trace 2 (yellow) is USB-C VBUS measured at the USB-C connector (upstream of the TPS65987D powerpath).  Trace 3 (green), when present, is the PGOOD signal from the barrel jack protection circuitry to the TPS65987D.

    In this first trace, the board starts with both barrel jack and USB-C connected.  V_SYS is at 12V, provided by the barrel jack.  At the trigger point, V_SYS has just fallen below the PGOOD threshold.  It rapidly falls below 5V, shutting down the board.  About 300ms later, V_SYS rises up to 15V when the TPS65987D has re-negotiated and closed its powerpath.  Through the entire event, VBUS_USBC is at 15V.

    The second trace is a zoomed-in version of the first, showing the transient behavior when the barrel jack input drops below its PGOOD threshold.  You can see that there is a bit less than 1ms between V_SYS crossing 10V and crossing 5V.

    In this third trace, the board is operating at a lower power state, so V_SYS falls slower.  In this trace, we can see that the TPS65987D starts to close its powerpath, as VBUS_SYS starts to rise again after about 3ms, but it's too late as V_SYS has already fallen below 5V and the board is shutting down.

    The fourth trace repeats the above test, but with the board in an even lower power state (most rails turned off).  V_SYS falls much slower, and almost 4ms after the VIN_PGOOD is deasserted, VBUS_SYS starts to ramp up again.  Squinting at this waveform, the ramp rate looks about right for what's configured, but it also looks like the powerpath soft-start ramp always starts at zero, and V_SYS only starts to rise when that ramp intersects the value that V_SYS is precharged to.

    If it were possible to disable soft-start and have the powerpath close immediately, or if the soft-start ramp started at whatever voltage V_SYS was already precharged to, it'd work.  Alternately, I may be misinterpreting this, and it might be an issue of response time -- ie the TPS65987D takes several milliseconds to detect and respond to the deassertion of VIN_PGOOD, in which case we'd need a way to make that response time faster.

    Thank you!

  • 0 in reply to Jonny Hall
    TI__Genius 14955 points

    Hi Johnny,

    Thanks for the update! 

    These captures are great and yes I would still want the PD log.

    Can you please provide me with a project file and a binary of your project so I can test this on my end on an EVM?

    Looking forward to your reply!

    Thank you,

    Kevin

  • 0 in reply to Kevin Kosta
    Prodigy 65 points

    Hi Kevin, I sent the project file & binary to you via private message -- just wanting to check if you received those & if you need anything further from us to investigate.  Thanks!

      -Jonny

  • 0 in reply to Jonny Hall
    TI__Genius 14955 points

    Hi Jonny,

    I never received an email notification but I just saw the message!

    I will look into this and get back to you by the end of the week!

    Thank you,

    Kevin

  • 0 in reply to Kevin Kosta
    Prodigy 65 points

    Thanks Kevin, just wanted to check in and see if you had any updates on this.  Happy to do more testing on our end if you have anything for us to try!

  • 0 in reply to Jonny Hall
    TI__Genius 14955 points

    Hi Jonny,

    Sorry for the delay on this!

    I will get someone else on my team to look at this if I do not have time myself!

    Thank you,

    Kevin