TUSB4041PAPEVM: CDP detection does not work if USB PD starts DCD before data pins make contact

Hi Tomasz:

   Do you mean TUSB4041 CDP works fine in your  product, btu only failed on TUSB4041 EVM?

Regards

Brian

No. When I write TUSB4041 I mean the TUSB4041 installed on TUSB4041PAPEVM. I don't quite know what silicon other CDP ports use, but it is not TUSB4041.

TUSB4041PAPEVM CDP identification with USB PD in question works correctly only under two conditions:

• Data pins make contact before USB PD starts DCD. For example when cable is already connected and USB PD reset button is pressed, or when cable is connected and TUSB4041PAPEVM slider moves from Off to Self-Powered position.
• USB PD chooses to not perform Data Contact Detect at all (300 ms timeout work, but so does virtually any timeout, even much longer timeouts than the maximum 900 ms allowed by BC1.2 do work).

Hi Tomasz:

    From EEPROM file, only port 3 and port 4 are enabled for battery charging. So the EEPROM was installed on EVM and SCL/SDA  switching to ON position (switch 1 pin 3 and 4)?

   if  EEEPROM was used, can you change  0Ah register from 70 to 20?

  Did upstream port connected?

Regards

Brian

Yes, the EEPROM is installed on EVM. SW2 pin 1 is ON, rest are OFF. SW1 pin 3, 4, 7, 8 are ON, rest are OFF.

I did change 0Ah register from 70 to 20 and observe no difference at all.

The upstream port is connected. If upstream port is disconnected then hub used to be detected as DCP but now I seem to get some strange VBUS on and off sequence. However, I would prefer to keep DCP operation out of scope here.

HI Tomasz:

   Did you test with other PD device?  TUSB4041 passed BC1.2 CDP compliance test.

Best

Brian

I tried with my phone, but unfortunately it does not implement DCD. The phone implements ~660 ms delay after which it proceeds to Primary Detection.

Can I get the TUSB4041 BC1.2 certification report?

ok, Let me find out.

Best

BrIan

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/Port1_5F00_CDP-_2800_1_2900_.PetRpt

Here is the test  report.

Best

Brian

Thanks for the report. I looked at the report and noticed that DCD is not tested. The "Emulate attaching PD" phases directly proceed to Primary Detection where VDP_SRC is enabled.

Do you have any test reports related to DCD? TUSB4041PAPEVM seems to not respond to Primary Detection if during Data Contact Detect the D+ line was at ~200 mV.

The USB PD implements DCD using the RDM_DWN method which is one of the two allowed methods according to Battery Charging Specification, Revision 1.2 3.4.1 Data Contact Detect Timing "To initiate Data Contact Detect, the PD shall enable IDP_SRC and either IDM_SINK or RDM_DWN".

I don't think we have other test report, do yo know which PD device has DCD?  so I can test in our lab.

Best

Brian

I managed to find in a rather considerable stash of phones, a mobile phone that seems to exhibit pretty much the same behavior with TUSB4041PAPEVM.

The mobile phone is Samsung Galaxy J3 (2016) running Android 5.1.1. Externally the root cause behind misdetection seems to be the same as with the USB PD I initially observed the issue on. I do not have access to any internal signals on the Samsung Galaxy J3 (2016) and therefore I could only capture the externally visible signals.

Channel 1 is VBUS

Channel 2 is D+ at the Samsung Galaxy J3 (2016) connector

Channel 3 is D- at TUSB4041PAPEVM port 4 through hole connector pin

Channel 4 is D+ at TUSB4041PAPEVM port 4 through hole connector pin

From the waveform it is clear that the phone started DCD before data pins made contact (channel 2 is at VLGC_HI while Channel 4 is at GND), then there is ~200 mV signal on D+ when the data pins made contact. Then after TDCD_DBNC (here 16.3 ms, which is more than required minimum 10 ms) the IDP_SRC is turned off. Then ~12.2 ms later the Primary Detection starts. TUSB4041PAPEVM does not enable VDM_SRC and therefore the CDP is misdetected as SDP.

Thanks for all  the evaluation . It seems a real bug for  TUSB4041 CDP charging.

Best

Brian

Will you follow up with root cause analysis and errata? If there would be root cause analysis performed would it be possible to access it (not necessarily in public)?

I  was told it's very hard to update Errata at TI , maybe endup with  Datasheet changes, I will let you know what we are going to do for this bug.

Best

Brian