• TI Thinks Resolved

TPD4S014: TPD4S014 ACK behavior on VBUS removal

Part Number: TPD4S014


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?



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

    Best regards,
  • In reply to Feifei Shen:

    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.


  • In reply to Feifei Shen:

    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.

  • In reply to Christopher Biele:

    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,