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.

TPD4S014: TPD4S014 ACK behavior on VBUS removal

Part Number: TPD4S014

Hello,

I am currently using the TPD4S014 in multiple designs and on odd behavior has been noticed on all 3 designs.  When the VBUS is removed (USB cable is detached) the ACK signal is de-asserted (as expected) after it crosses below UVLO-.  Strangely, after a long period of time (roughly 600mS) it is re-asserted for about 750mS before de-asserting again and staying that way.  The timing is consistent on each design, but is marginally different between the designs.  I've arrached a scope capture of VBUS (green) and ACK (yellow).  All devices are powered via a single Li-Ion battery.  The ACK signal is connected directly to an MSP430 input pin and pulled up to VCC (3.3v) with a 10K resistor.

Is this typical behavior or to be expected?  If not any ideas on what could be the source of this bahavior?

Thanks

-Chris

  • Hi Chris,
    The waveform looks strange. Can we remove the 430 pin, and whether the phenomenon can be duplicated?
    Thank you.

    Best regards,
    Feifei
  • Good idea.  I'll give it a try.  

    I'll get the same screen capture with the processor halted, with an uprogrammed part, and with the trace disconnected and report back tomorrow.

    -Chris

  • I've repeated the experiment today and there was no improvement. The waveform actually looks a bit different today with an extra 'glitch'.

    I took the same 2 screen captures in 4 different configurations. The first capture was on application of VBUS and the second was on removal of VBUS. The four configurations were as follows:
    1-No modifications, MSP430 running firmware (duplicate of original post)
    2-MSP430 execution halted.
    3-MSP430 erased.
    4-ACK trace between TPD4S014 & MSP430 cut, with 10K pullup to 3.3v on the TPD4S014 side.

    The application of VBUS in all configurations looked great.  The removal of VBUS still exhibits oddities I cannot explain for an open-drain output pin.  Unfortunately, in all configurations the result was the same (attached below). There seems to be an extra 'glitch' today that I cannot explain. Ignoring this, the overall waveform still exhibits the initial problem that I cannot explain. We are working around it in the firmware, but I see this as a band-aid approach.

  • Hi Chris,
    Thanks for the update, we may need order the EVM and double confirm later since it's a old device.
    It may take 2-3 week.

    Best regards,
    Feifei
  • Hi Chris,

    I have the EVM on order to run this test, but it still has not arrived at my desk. This message will re-open this request and I will keep it open until I have provided you the requested information.

    Regards,
    Chuck
  • Thank you for the update Chuck.  Looking forward to what you find.

  • On your board, what value of Capacitor do you have on VBUS and VBUSOUT?

    I want to make sure that I configure the EVM as closely as possible to your system when I begin testing.

    Regards,
    Chuck
  • 10uF on the input and the output

  • Chris,

    I have confirmed the behavior that you are seeing on my EVM. I see the exact behavior when I have the same capacitor and zero load settings.

    What I suspect is occuring is the VBUS voltage is remaining between VUVLO+ and VUVLO- longer than the internal hystersis for discharge.

    If this is the case, then the device is detecting that VBUS is below VUVLO+, and generating the first ACK. The second ACK is caused by VBUS remaining between VUVLO+ and VUVLO- longer than the design hysteresis, causing the second, much shorter ACK pulse that we are both seeing.

    Is it possible to add a blanking period on the Sample of the ACK signal after the first EDGE within your firmware to mask this double event from your system?

    I will follow up after more internal research.
  • Yes, we are currently handling this issue via a firmware blanking period. However we have found that for it to be sufficiently long to avoid the issue, we run into user-feedback delays that are not ideal. I think we may need to relay on other means to detect the USB cable is att/detached event.
  • Your USB microcontroller has to be able to detect a disconnect on the d+/d- lines by sensing the reflection created by the disconnect.

    Do you have access to this interrupt in your system?