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.

TPS65986: Device not clearing GPIO event for VBUS detect, and other GPIO configuration

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-up
For #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?

 

Question-3

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.  

  • Question 3: Is not recommended to read data out of the registers since no valid data would be extracted.  

  • Hi Eric,

    I've been seen some issues with the GUI tool. I will try to get them fixed and analyze why is this behavior shown.

  • Hi Eric,

    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.

    Regards,

    Francisco Lauzurique

  • 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.

  • Hi Eric,

    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.

    Regards,

    Francisco Lauzurique

  • Francisco,

    1. I have not been able to re-create on a booster-pack, because I can not get my Config Tool to talk to my EVM, not sure what is going on, I've used it several times in the past, but having trouble now.  That said, the customer is reading these status values out of the GPIO register, and the GPIO mentioned are both very simply configured to be:   Initial value: 0x0,     Output leve: LDO3V3,     Mapped Event: Plug Event and VBUS Detect Event.   The open-drain and pull up/down boxes are NOT checked.   So in simple plug / un-plug event, they should see both GPIO go to "1", then when plug is removed, both should go to "0".  Correct?  They are seeing the Plug Event return to "0", but the VBUS Detect Event is remaining "1", even with no plug, thus no VBUS.  Have we ever seen similar behavior?  Can you try on EVM with sample Project and 2 GPIO configured as I described?
    2. Is it possible to consider adding "Input Enabled Without Event" as an option in Configuration?   It seems like a reasonable and potentially useful use-case for a GPIO, particularly if several are left "unused" as of now.  Allow the system to read certain status, and the Host could take necessary actions, etc.  Please advise if this is possible to add to the list of programmable GPIO configurations.

    Thank you,

    Eric.

  • Eric,

    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? 

    Hari

  • Hari,

    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.

  • Eric,

    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

    Regards,

    Hari