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?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
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.
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:
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.