TPS65987DDK: USB PD failing to communicate data

Possibly related to this issue, when I attempt to debug this scenario the configuration register settings change of their own volition (for example, PD mode is port control 0x29 is set to Normal PD Behavior but then I'll check it while in debug mode and it has changed to Legacy USB Device/Sink).

Here is an advanced project that I have also been trying to use: Cayetano_TPS65987_Firmware_DataComm_Advanced.pjt

Hi Jacob, 

What is the expected power and data role of TPS65987 when connected to a far-end device (tablet, laptop, etc.)? Is the TPS65987 system suppose to act as a DFP source, UFP sink, or some other combination? 

With the devices you have tested, do they have PD capability or are they Type-C only ports (does not support Power Delivery, only legacy Type-C source or sink)? Based on your testing with re-routing D+/D- line and TPS65987D detecting Legacy USB Device, it seems like the far-end device you've tested with are Type-C only but would like to clarify with you first. 

Thanks and Regards,
Raymond Lin

Hello Raymond, thanks for the response.

The intended power role of the TPS65987 is source when the battery and far-end device are connected. The intended data role is no preference as I understand it since the board will need to send data to the tablet and vice versa.

We have tested using a Samsung Active Pro 3 tablet and a few different laptops, all of which are PD capable devices. I included the legacy setting mode as an example of that configuration instability issue, but I've seen a bunch of other settings seem to go awry as well including port configuration (changes from DRP to UFP or disabled), USB3.0/3.1 rate (changes to not supported), the process and initiate swap bits, externally powered and automatic sink cap bits, source and sink capabilities, etc. I've determined that these settings change when I disconnect the battery (TPS65987DDH swaps to sink from far-end device), but I am unsure of the root cause.

Thanks,

Jacob Cayetano

Hello Jacob, 

I will look into this and get back to you. 

Regards,
Deepak 

Thanks Deepak.

Another bit of information that I've found is that data will work with a USBA-USBC cable from a laptop to our board. The same exact setup with a USBC-USBC cable does not work. We require the USBC-USBC connection to work since the actual use case is with a Samsung tablet.

- Jacob Cayetano

Thanks for the info. That was helpful. 

Hello Jacob, 

The project file looks alright. 

I have a project file in the attachment below: Reason is to check to see if one setting could be causing any issue -
Cayetano_TPS65987_test.pjt

Please do let me know once you have tested this file and you have results. 

Regards,
Deepak 

Hello Deepak, thank you for your response.

That project file had the same results as previously observed with no differences. However, we have made some progress since my last message.

We were able to get USBC-USBC data connection to work on laptops and a Microsoft Surface by changing the firmware settings to be USB2 only. As far as we are concerned, the USB connection between Windows systems and our board is completely verified at this point. However, our use case is for an Android tablet, and those still have issues.

We have been able to get data between an Android tablet and our board using a specific orientation of this cable. However, the orientation of the USBC cable in which data works correctly does not allow the board to charge the tablet. If the orientation is flipped (swap plug ends), the tablet is able to charge but no data comes through. Our use case is that we want data to be transferred between the tablet and board while the board is charging the tablet (or the tablet is powering the board when the board battery is removed or dead).

Other cables that we have tried tend to only charge the tablet. We have also inconsistently seen an attempt to establish a data connection with some other USBC cables, but they do not successfully transfer data. We have only seen data between the board and tablet work properly with the cable linked above.

Thanks,

Jacob Cayetano

Jacob, 

Does this issue occur only with the cable you have mentioned above ?

Also, could you provide us CC captures of the normal orientation and flipped orientation. 

Regards,
Deepak 

Hello Deepak,

Data orientation: CC1 at 0V, CC2 at 0.45V

Charging orientation: CC1 at 1.74V, CC2 at 0.42V

If you need the capture of CC lines on the oscilloscope at the moment of cable connection, let me know.

Our data transfer issues occur with all cables, but the cable linked above was the only cable were we able to get working data transfer until some more progress yesterday. We were able to get one of the cables we were originally testing with to work (charging the tablet and transferring data simultaneously), but only after a very weird sequence of steps involving disconnecting and reconnecting the battery that is not repeatable for the end use case and not reliable either.

The bottom line of all of this is that we seem to have issues with role swapping. I have also been able to fix the state of our setup in debug mode by issuing commands to swap to UFP/DFP or swap to source/sink, but the firmware should be set up to do that automatically.

Thanks,

Jacob Cayetano

Hello Jacob, 

As per the working of the PD controller. The PD would first need to negotiate a contract. The Voltage on the CC lines needs to be as given below: 



In the charging scenario we can observe the CC line voltage are correct. However, the voltage is not correct with respect to data orientation. And hence we cannot charge while in the data orientation. 

I will once again look through the project file settings and get back to you if any configuration is missing. 

Regards,
Deepak