Part Number: TPS65986
Question-1: For our GPIO config, we have GPIO 0 = 'Plug Event', and GPIO 5 = 'VBUS Detect Event'. What we are seeing is if we connect a USB-C PD charger and then detach it, the VBUS detect GPIO stays high. Dumping the TPS65986 GPIO register, it reports that it is driving the line high:
GPIO 0: 0 (direction = output, supply = LDO_3V3, drain = push-pull, pull-down = disabled, pull-up = disabled)
GPIO 5: 1 (direction = output, supply = LDO_3V3, drain = push-pull, pull-down = disabled, pull-up = disabled)
So this shows TPS65986 indicating nothing is plugged in, but it detects VBUS.
We can 'fix' this by attaching a DCP, SDP or non PD USB-C charger. For PD chargers, we tried with 2 internal PD products, and a few Google PD chargers, all with the same result.
Any thoughts? This a known issue?
Question-2: we have a status GPIO going into GPIO1 of the TPS65986. We didn't want to tie any GPIO events to it, we just wanted to: > 1) Read the state of the GPIO at certain times > 2) Enable the internal pull-upFor #1, I had verified an eval kit that even when the config tool reports a GPIO as disabled, it is still configured as an input and you can read the real time state via register 0x72.But for #2, running into a problem. The config tool only exposes an option to change the pull-up config only if you assign a GPIO event. However, there isn't really a 'generic input' event that I could find. > Any guidance on how to accomplish what we want via FW?
if a GPIO is configured as 'disabled' in the config tool, does the GPIO data in register 0x72 reflect the real-time status of what is being input into TPS65986? I had thought that was the case from what I saw using the eval kit, but seeing confusing results on our protos. With same input level, I'm getting different values in 0x72 if I config as disabled vs "Load App 3". Can you please advise if the "disabled" GPIO will still be sampled and reported in 0x72 as an input with valid levels we can read?
Question 1: I will go ahead and do some testing on my part in order to see if this is a possible bug.
Question 2: You can write to GPIO registers only when uploading the app conf. but not during run time. Register will take the command and clear up within a few seconds.
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 Francisco Lauzurique:
Question 3: Is not recommended to read data out of the registers since no valid data would be extracted.
I've been seen some issues with the GUI tool. I will try to get them fixed and analyze why is this behavior shown.
I am sorry for the late response. I was having issues with my FTDI drivers. I would suggest uninstalling the FTDI drivers from within where the application customization tool was installed and try installing another version of the FTDI drivers. Within the same folder we currently have 3 other versions. Try one of those. I though it was a GUI issue, but after using the Tiva microcontroller to access the EVM I figured out it was my FTDI drivers. Let me know if this method works for you.
I'm sorry, but I really don't understand all responses:
Question 1: Are you implying the problem they are seeing is related to FTDI drivers? They are seeing the Plug Event GPIO changing state appropriately, but the VBUS detect Event GPIO is not changing "back" to '0' when they unplug the cable. Are you not able to reproduce this with FTDI driver re-install? Why would one GPIO change back, but not the other?
Question 2: I fear I wasn't totally clear... they are not trying to write at run-time, but in order to configure the Internal Pull-Up as part of the App Config, they must first select a GPIO type from the drop-down list of options. All the options are tied to specific events, there is no "generic input" they can select that will bring up the buttons to allow them to configure internal pull-up to be active. For example, there is an "Output Enabled Without Event", they are essentially looking for an "Input Enabled Without Event" option. Any way to achieve this?
Question 3: Why would no valid data be extracted? This GPIO Status Register 0x72 is part of the Host Interface TRM, and Bytes 1-4 contain the Data Logic Levels. I don't understand why this would be invalid data? Please explain further. If they have a GPIO (say GPIO6 for this example) configured to be an Input, then I don't understand why Register 0x72, Byte-1, Bit-6 would not contain the current state of that Input??? please help me understand.
In reply to Eric S:
1- Can you try reproducing the same behavior using the TPS65986 BoosterPack. If this work, can you share your project files with me to verify the behavior.
2- We do not support an Input Enabled Without Event. I am sorry.
3- If you are configuring a GPIO as "Disabled", you would not be able to get any valid data out. This is why when comparing data with "Load App 3", the data points do not match. After setting a GPIO as "Disabled, is not recommended to read data out since the data would be invalid.
Are you wondering the output for the GPIO events? So you mapped the same event to both GPIO pins and what you see is that the VBUS Detect Event stays high with no input?
I'm not sure I understand what the customer wants to achieve. So they want to have an input on a GPIO pin and have it set high at all times? What is their input to the system?
In reply to Hari Patel1:
I'm sorry it's not clear... Going back to the very first original post on this, they have 2 GPIO Events configured:
GPIO 0: "Plug Event" (direction = output, supply = LDO_3V3, drain = push-pull, pull-down = disabled, pull-up = disabled)
GPIO 5: "VBUS Detect Event" (direction = output, supply = LDO_3V3, drain = push-pull, pull-down = disabled, pull-up = disabled)
Both start at "0" like they should. When they plug-in a PD Charger, both GPIO transition to "1" as they should. When they UNPLUG that charger, the "Plug Event" transitions back to "0" like it should, but the "VBUS Detect Event" (GPIO 5) remains as "1", indicating that VBUS is still present. So it sees that the charger is unplugged, but it's indicating that VBUS is still there, which it clearly can not be.
This currently only seems to happen with PD Chargers that they've tested. Does not happen with DCP, SDP, or non-PD Type-C chargers.
I tried a similar scenario on my EVM and it seems to be working fine. Could you provide some CC and PD logs so I can take a closer look into it. Also, when you were testing after you detached it, did you check the VBUS directly on the device? If you are using an EVM, there is a testpoint for checking VBUS and you can test that as well to see if it might be a GUI issue. I would also recommend using the most updated GUI and firmware version.
You can also refer the the GUI's user guide here: http://www.ti.com/lit/ug/slvub60a/slvub60a.pdf
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. 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.