TPS65987D: Fault clearing on cable insert/remove

Hi Darren,

Would you be able to share the project file the customer generate using the GUI? Also, are you testing this functionality on the EVM or a customer system? If it is a customer system, would you be able to share a screenshot of the GPIO on the PD controller and any external connections? 

Hi Adam,

I sent the files to you by email.

Thanks,

Darren

Hi Darren,

I looked as the host interface document and the GUI and the Port 0 Fault_Condition_Active_Low_Event is the same as Port 0 FaultZ Output Event. You can check this as well by using the GUI. Under the settings tab is the option to "Show Raw Field Values". Once you enable this and then go the GPIO 20, you will see that Port 0 FaultZ Output Event has a value of 59, which is the same event number for Port 0 Fault_Condition_Active_Low_Event in the host interface document. 

This GPIO event should only be triggered in the event of an overcurrent event on VBUS. How is the customer simulating an overcurrent event on the connector to determine functionality of this specific GPIO event. 

Hi Adam,

The customer is seeing the GPIO pin is high, then it goes low on PD renegotiation, and it never goes back to high.  

The customer isn't doing anything to create an overcurrent event, and doesn't think there is an overcurrent.

This GPIO pin connects to a device on the USB port, forcing this port to isolate, since it's perceived as an overcurrent event.  

How can it be cleared?  Of course we'd like to know why it's happening in the first place as well.

Thanks,

Darren

Hi Darren,

Does the customer have access to an oscilloscope with a current probe? If so, would they be able to take a capture measuring the following channels?

• VBUS voltage
• VBUS current
• Voltage of GPIO programmed to Port 0 Fault_Condition_Active_Low_Event
• Voltage on CC1

With these channels would the customer be able to capture the following sequence in a single scope capture:

1. Start with the TPS65987D powered off 
2. Power on the TPS65987D via VIN_3V3 so that it can load the configuration from the external EEPROM
3. Connect the USB device to the Type-C port
4. Remove the USB device from the Type-C port

Hi Adam,

The customer doesn't have a current probe, but can capture a current measurement using a Math function on his scope.  It's fairly noisy, but he can see that the only current spike is on the plug-in when Vbus transitions from 5V to 20V.  The current goes up to about 1A.

On cable removal, there is no current spike.  This is when GPIO20 gets driven low.  VBUS ramps down from 20V to 5V over 1.5ms.  The transition on GPIO20 aligns with when VBUS passes the 5V mark.

GPIO20 never goes high again, even after plugging in a cable again.

Thanks,

Darren

Hi Darren,

Thank you for the additional information. I've attached a test project file that is very similar to the one originally provided, except that the overcurrent interrupt event has been enabled for I2C1_IRQ. This is an open drain pin, so an external 10k pullup will be needed to connect to LDO_3V3 if it is not already.

The idea is that when this is the only IRQ event enabled, if we see this pin go low, we know that an overcurrent event is occurring during a disconnect, and the GPIO is behaving as expected. If we see this GPIO remain high, then we know something is occurring with the GPIO event itself.  

test1.pjt

Another idea is using one of the GPIO tests points on their board, reconfigure the GPIO so that it operates as the default fault output GPIO event. Measure the GPIO when a device is removed from VBUS and see if it mirrors what the customer is seeing for GPIO 20

Finally, would you be able to have the customer walkthrough how this pin is being used and the intent for it? Looking through the schematic, I do not see how it can be used as an open drain output as well as the reason for tying it to the TPS56637. Any help on this would be appreciated

Hi Adam,

Following up on the message I sent you internally.  The customer has a pull up on I2C1_IRQ.  The I2C1_IRQ pin stayed high the whole time through the disconnect and reconnect.  The GPIO20 pin did the same thing as before, where it goes low and then never returns high.

He also configured GPIO 1 to match what you have in the picture : Port 0 FaultZ Output Event.  The GPIO 1 behaved the same as the GPIO20 did before, but inverted.  This caused GPIO20 to stop working (as expected since an event can only be tied to one pin). 

Can you describe how Port 0 Source Power Greater Than works?  Is it actually a VxI measurement and calculation, or just I?

Thanks,

Darren