TUSB320LAI: Failing USB-IF TD 4.3.4 Sink Connect Try.SNK DRP Test

Hi Don,

Would you please provide your VIF file and your Teledyne LeCroy software version?

Nicholaus,

Thanks for responding.

The tests are being run by GRL and they are sharing the resulting files with me.  Last run was on the 7.68, build 2771 version.

;
; USB-IF Vendor Info File Generator, Version 1.2.2.1
;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;   Intro tab
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
$VIF_Specification: "Revision 1.35, Version 1.0"
$VIF_Producer: "USB-IF Vendor Info File Generator, Version 1.2.2.1"
$Vendor_Name: "Crossmatch"
$Model_Part_Number: "900469-7680"
$Product_Revision: "A"
$TID: "10007755"
VIF_Product_Type: 0        ; Port
$Port_Label: "J1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;   VIF Product tab
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Connector_Type: 2        ; USB Type-C™
USB_PD_Support: NO
Type_C_State_Machine: 1        ; SNK
Port_Battery_Powered: YES
BC_1_2_Support: 0        ; None

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;   USB Type-C tab
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Type_C_Is_VCONN_Powered_Accessory: NO
Type_C_Is_Debug_Target_SNK: NO
Type_C_Can_Act_As_Host: NO
Type_C_Can_Act_As_Device: YES
Type_C_Power_Source: 2        ; Both
Type_C_Port_On_Hub: NO
Type_C_Supports_Audio_Accessory: NO
Captive_Cable: NO
Type_C_Sources_VCONN: NO

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;   USB Device tab
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Device_Speed: 0        ; USB 2
Device_Contains_Captive_Retimer: NO
Min_Operating_Voltage: 100        ; (5000 mV)
Max_Operating_Voltage: 100        ; (5000 mV)
Max_Operating_Power: 1200        ; (12000 mW)
Max_Peak_Power: 1400        ; (14000 mW)
Max_Peak_Power_Time: 6553        ; (655300 mS)

Thanks Don,

I will head to the lab and attempt to reproduce this issue. I will follow-up as soon as I am done.

Hi Don,

I have reproduced your issue with the TUSB320 . I'm still waiting to perform this test with the TUSB320LA. Thank you for your patience. Do you also have the results for the TUSB320? If it did in fact pass on your end, then I would like to know so I can determine differences in our setups.



Thanks,

Don,

I received my TUSB320LAI units this morning and I am ready to begin testing; however, I noticed something in your setup that may be causing the CC line issue.

The TUSB320LAI has 3 modes. DFP, UFP, and DRP. According to your description it seems you have the TUSB320LAI set to UFP mode, but the 4.3.4 test you are running is designed for DRP. In order to do this you must have the PORT pin set to No Connect, if you change this, does it correct the problem?

Also, in regards to your VIF file. Would you confirm that this is true for your product?

Type_C_Supports_Audio_Accessory: NO

Nicholaus,

Sorry about disappearing.  I have been on vacation for two weeks.

Type_C_Supports_Audio_Accessory: NO         This is true.  We are a simple UFP only device.

I have questioned whether the 4.3.4 Sink Connect Try.SNK DRP was to be run on a UFP but I could find no way that the VIF could be adjusted to stop the test from being run.

Would you know how the USB-IF maps the verification tests to the specifications?

I now am a member of USB-IF and hope to find some time to find someone to help with the test specification intentions.

I have assumed that the test is being run to be sure that the DUT responds correctly to a Try.SNK DRP by ignoring it (Always showing Rd).

This is why I am involving the experts.

I hope to get some time to change out the device to a TUSB320RWBR and get it sent out to GRL for a spot test of 4.3.4 this week.  It seems that every time I try to work on this some stupid thing comes up to interrupt me. I will also try to figure out how the VIF and USB_Type_C_Functional_Test_Specification_2018_05_28 map out to make sure that 4.3.4 should actually be run.

Thanks, Don

Hi Don,

No problem, I have done some more research into this 4.3.4 test, and I think it should work on a UFP device. You are correct, the CVS is the device that is acting as a DRP and the device should be able to handle both cases.

I was wondering if the pulses in the CC lines were caused by audio accessory, but that is not the case either. I should be able to get in the lab and do more testing today, and I will follow-up with the results.

Hi Don,

I ran some tests today, and I was unable to find a production device that passed the USBIF 4.3.4 compliance test. I will test more devices tomorrow; without first having a device that passes this test I cannot test the TUSB320LAI.




Regards,

Nicholaus,

The http://www.ti.com/tool/tusb320evm may work because I don't get the pulses from it. The test can be run with the EVM and a PC that is running the USB-IF USB 2.0 test suite.

I tried today to put a TUSB320RWBR in a unit but it failed to work at all, most likely due to a lack of soldering skills and proper rework equipment.  I will troubleshoot tomorrow.

Below are the 4.3.4 steps and they should all work with a PC connected to the EVM as the USB source in 9-i below.

TD 4.3.4  Sink Connect Try.SNK DRP Test

 

 

A. Purpose

1. Verify a Sink transitions to Attached.SNK according to spec

B. Applicability:

1. This test applies when VIF field Type_C_State_Machine is SNK and Type_C_Supports_Audio_Accessory is NO and Type_C_Supports_VCONN_Accessory is NO.

C. Asserts:

1. TBD

 

D. Procedure:

1. CVS transitions to Unattached.SRC for 5ms

2. CVS transitions to Unattached.SNK for 30ms

3. CVS transitions to Unattached.SRC

4. CVS verifies PUT continues to provide Rd on the CC pin for the duration of this test

a.     For a PUT_R, verify Rd is provided on both CC pins until Attached, and then on at least one CC for the duration of this test.

5. CVS transitions to AttachWait.SRC for tCCDebounce

6. CVS transitions to Try.SNK for tDRPTry

7. CVS transitions to TryWait.SRC for tCCDebounce

8. CVS transitions to Attached.SRC

9. CVS verifies that PUT transitions to Attached.SNK:

a.     PUT sinks current according to CVS advertisement

b.     If PUT supports USB 3.1:

i.      PUT starts data communications on its SuperSpeed pairs.

c.     Else if PUT supports USB 2.0:

i.      PUT starts data communications on its D+/D- pair

d.      For a PUT_R, VCONN is not applied

10. CVS transitions to Disabled

11. CVS verifies that PUT transitions to Unattached.SNK before tVBUSOFF expires a.           PUT data communication has ceased

b.     PUT is not sourcing Vbus (Vbus is at vSafe0V)

c.     PUT is not sourcing Vconn

 

Nicholaus,




The www.ti.com/.../tusb320evm may work because I don't get the pulses from it. The test can be run with the EVM and a PC that is running the USB-IF USB 2.0 test suite.


I tried today to put a TUSB320RWBR in a unit but it failed to work at all, most likely due to a lack of soldering skills and proper rework equipment. I will troubleshoot tomorrow.


Below are the 4.3.4 steps and they should all work with a PC connected to the EVM as the USB source in 9-i below.


TD 4.3.4 Sink Connect Try.SNK DRP Test





A. Purpose

1. Verify a Sink transitions to Attached.SNK according to spec

B. Applicability:

1. This test applies when VIF field Type_C_State_Machine is SNK and Type_C_Supports_Audio_Accessory is NO and Type_C_Supports_VCONN_Accessory is NO.

C. Asserts:

1. TBD



D. Procedure:

1. CVS transitions to Unattached.SRC for 5ms

2. CVS transitions to Unattached.SNK for 30ms

3. CVS transitions to Unattached.SRC

4. CVS verifies PUT continues to provide Rd on the CC pin for the duration of this test

a. For a PUT_R, verify Rd is provided on both CC pins until Attached, and then on at least one CC for the duration of this test.

5. CVS transitions to AttachWait.SRC for tCCDebounce

6. CVS transitions to Try.SNK for tDRPTry

7. CVS transitions to TryWait.SRC for tCCDebounce

8. CVS transitions to Attached.SRC

9. CVS verifies that PUT transitions to Attached.SNK:

a. PUT sinks current according to CVS advertisement

b. If PUT supports USB 3.1:

i. PUT starts data communications on its SuperSpeed pairs.

c. Else if PUT supports USB 2.0:

i. PUT starts data communications on its D+/D- pair

d. For a PUT_R, VCONN is not applied

10. CVS transitions to Disabled

11. CVS verifies that PUT transitions to Unattached.SNK before tVBUSOFF expires a. PUT data communication has ceased

b. PUT is not sourcing Vbus (Vbus is at vSafe0V)

c. PUT is not sourcing Vconn

Don,

I believe the TUSB320EVM with the PC is one of the first tests I tried and it failed. I will try that test again. Does it work for you?




Regards,

Nicholaus,

I was able to get the TUSB320 into our device and working.

It does seem to have solved the problem.

Below are scope captures of the TUSB320LAI and then the TUSB320. 

I believe that the thing that is causing the failures is that blip on CC1 to the left of cursor b that shouldn't be there if the TUSB320LAI only presented Rd in UFP mode as advertised in the datasheet. It appears that the TUSB320LAI is defaulting to DRP if the CVS presents as a SNK even though it is not in DRP mode.

This test is a TUSB320 EVM being used as a CVS connected to our devices, one with the TUSB320LAI and the other with the TUSB320.  On the CVS surrogate I first disable the Rp / Rd for half a second and then I enable SRC for 5ms then SNK for 30ms then SRC for 20ms then SNK for 150mS and then finally SRC for 200 then disable the Rp / Rd.

There are a few things that don't make sense about the timing in this test, I think that because I reset the state machine to get the device to disconnect and change from DFP to UFP some of the timing is off.

One difference between the TUSB320 and the TUSB320LAI is the addition of Accessory Mode (audio and debug) when configured as UFP.  The TUSB320LAI supports this feature while the TUSB320 doesn't.  Refer to Table 1 in datasheets.  This feature is enabled by default for the TUSB320LAI.  It can be disabled by setting bit 0 (DISABLE_UFP_ACCESSORY) in Register 0x09.

A general comment on use the TUSB320 EVM boards is to make sure the I2C controller is not plugged into the EVM when power on the EVM board.  The TUSB320's SDA and SCL pins are NOT failsafe.  If you leave I2C controller plugged into EVM board, then it will back drive the TUSB320 causing it to not get reset properly.  Always plug into I2C controller after powering on the EVM board.

Hi Don,

I'm glad that the TUSB320 worked! I do not have your complete system setup here in my lab, so I the best comparison I can have is a passing/failing result with the LeCroy analyzer. I want to be sure that your working system corresponds to a passing LeCroy test, so then I can work towards reproducing this issue and then finding a possible fix. Can we get the data for LeCroy CVS -> TUSB320 -> Device?

As Mike mentioned, the pulses could be caused by Audio Accessory detection, please try disabling this feature and see if the pulses go away.




Thanks,

Nicholaus and Michael,

That was it.

Setting BIT 0 in register 0x09 stopped the pulsing.

Here is how I got wrapped around the axel:

I am designing a product that is a simple UFP.  I chose the TUSB320LAI because it was newer and cheaper.  We are using the GPIO functionality so that charge rates can be set while the unit is off.  Reading the datasheet I went by the paragraph below:

7.2.1.2 Upstream Facing Port (UFP) - Sink

The TUSB320 device can be configured as a UFP only by pulling the PORT pin low to GND. In UFP mode, the
TUSB320 device constantly presents pulldown resistors (Rd) on both CC pins. The TUSB320 device monitors
the CC pins for the voltage level corresponding to the Type-C mode current advertisement by the connected
DFP. The TUSB320 device debounces the CC pins and wait for VBUS detection before successfully attaching. As
a UFP, the TUSB320 device detects and communicates the advertised current level of the DFP to the system
through the OUT1 and OUT2 GPIOs (if in GPIO mode) or through the I2C CURRENT_MODE_DETECT register
one time in the Attached.SNK state.

Reading up on the Debug modes I just found USB Type-C Port Controller Interface Specification page 25 3.7.3 Sink with Accessory Support that describes the requirement for DRP functionality but with SINK only operation. 

So, because we are using GPIO mode I cant disable the accessory mode.

There are two ways to solve this:

1. Switch to the 320 that doesn't support the accessories (requires scrapping 2400 devices )
2. Declare accessory support even though we don't have them ( Problem - May have to demonstrate the functionality of non-existent accessory for USB-IF )

You may want to clarify and correct your documentation so that others novice engineers don't get run through the same wringer.

• Fix 7.2.1.2 to state that the device defaults to Sink with Accessory Support and that that operates in a similar fashion to DRP unless disabled in which case Rd is continuous. 
• Add a mention of the Sink with Accessory Support functionality to the document - in the 8.2.3.2 Detailed Design Procedure UFP perhaps.

Thanks for your help.

Don

Don,

Glad we figured that out. I will see if I can get the documentation updated.

I wanted to make you aware of a known behavior of the TUSB320 that was updated in the TUSB320LAI: If you try the TUSB320 in UFP mode, the initial configuration set by the DFP will be static, if the system updates it's configuration over time, the TUSB320 will not update. This shouldn't be a problem for compliance. If this is something that is relevant to your design, please read section 7.2.1.2 of the TUSB320 datasheet.

Let me know if you have any more questions.



Thanks,