• State Answer Suggested
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1720 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.

TPD3S714 USB protection with Microsemi USB2517 Hub

Eric Conner
Prodigy 150 points

We have designed in the  TI TPD3S714  protection devices on our 6-Port PUSB Hub.

We eliminated the USB power switches (MIC2026) because the TPD3S714 has the 500mA OC protection that shuts OFF +5V VBUS in over-current or fault condition.

However, every time the TI protection device is powered ON, it momentarily send a FAULT signal to the Hub.

This in turn causes the port to shut OFF the power. And with the power OFF, the fault is never cleared.

I verified this by holding the enable signal low until the inadvertent fault signal is cleared at power-ON. When this is done, the port enumerates normally and can be re-enumerated until the power is cycled again.

Is there any way to get around this a to delay or eliminate this power-On Fault signal. 

Attached is the schematic showing the first 5 ports protected with the TPD3S714 and one port (sixth) using the Mic2026.

The 6th port is the only port that enumerates the down-stream device.CyberData_PUSB_Hub_sch.pdf

  • 0
    Intellectual 670 points

    Hi Eric,

    The behavior you're experiencing is intended operation of the device.  When the TPD3S714 is powered on and above UVLO, but disabled, the device asserts FLT.  See below logic table from the TPD3S714 datasheet:

    If this is causing the hub to disable, my recommendation would be to add a simple OR gate to the FLT pin tied into the hub EN pin.  Here’s a quick example schematic of how to implement this:

    Our sister group over in SLL has a great selection to choose from: http://www.ti.com/lsds/ti/logic/or-gate-products.page

    With EN + FLT tied together, the FLT will only assert back to the microprocessor when the device is both enabled and asserting a FLT.

    Another alternative would be to switch to the TPD3S716 (link: http://www.ti.com/product/TPD3S716-Q1) which does not have the same FLT behavior.  It will not assert a FLT when powered on but not enabled, and also has an adjustable current limit with slightly better accuracy.

    Please let me know if you have any further questions.

  • 0 in reply to Jeff Harris
    Prodigy 150 points

    Hi Jeff,

     

    The OR-gate modification did not work.

    It seems that the TPD3S714 does not release the FAULT until it is enabled and the Hub chip will not enable the part until the fault is removed.

     So, the OR-gate /EN signal starts out High and stays high (disabled) for approx. 700mS.

    This is OK since this sends a high to the Hub-Fault.

    Then, after 700mS, the Hub attempts to enable the TPD3S714 (/EN goes LOW) but this in-turn causes a fault signal back to the hub before the TPD releases its fault.

    Therefore, the as soon as the hub tries to enable the port, a fault signal is relayed back and the port never turns ON.

     I did try another experiment of connecting a RC to the OR-gate instead of the /EN. This does allow the port to start if the RC decay is greater than 700mS. However, if there is any glitch on the fault line, the port shuts OFF until the power is cycled.

    Can you recheck to see on other possible solutions that will enable us to stick with the TPD3S714.

    Regards, Eric 

  • 0 in reply to Eric Conner
    Intellectual 670 points

    Hi Eric,

    Per our discussion on the phone, adding an RC decay circuit between hub /EN pin and the OR gate (while still connecting the EN without the decay directly to the 714) should have the correct response.  See this diagram below:

    Here's the simulation showing this should all work properly:

    This should effectively allow EN and FLT to all work properly.  You’re correct that there is a possibility of RC degradation, but if you set the value properly and high enough I don’t see that causing an issue.

    As mentioned, the TPD3S716 should obviously solve the problem altogether without using any extra passives.  Another alternate would be a delay circuit, but that may be a more expensive overall solution.

    A final alternative just leaving the TPD3S714 enabled and tied to ground.  Besides port management/power conservation, there’s not really a need to disable and enable the device.  It should be able to recover out of all faults by itself without intervention of the user (assuming the fault is removed).  Leaving the enable low would allow time for the fault to disable on powerup and should function without an issue.