TUSB321: Functional Test specification enquiry

Hi Alder,

There are quite a few steps in each of the functional tests. Can you share where in each of the tests we fail?

This E2E highlights the primary differences:

(14) TUSB321AI: ESD HBM difference between TUSB321AI and TUSB321 - Interface forum - Interface - TI E2E support forums

Hi Vishesh,

4.10.2 and 4.10.3 - with one orientation we are able to pass in LeCroy and with another orientation we are failing; for LeCroy we can also share the trace if this help. Let me know whether you can decode LeCroy trace file or you need the snapshot of trace.

Thanks,

Best regards,
Alder

Hi Alder,

Sorry for the delays, I was was out of office from 5/9 - 5/13. Yes please share the USB trace. 

Hi Alder,

Any update?

Hi Vishesh,

I overlooked the notification email, just saw this, let me get the trace for you.

Hi Vishesh, 

The file is big, >100MB, do you have any "file share system" that we can use to upload the data?

Thanks,
Best regards,
Alder

I created a shareable folder here:

https://tidrive.ext.ti.com/u/nfbTHCR20xuP9tML/270ef03f-5173-4c7c-b4da-3dab6f1ad8b2?l

password: x93ZA=BZ

Try uploading the files there.

Thanks Vishesh,

i had upload the trace to above shareable folder. This is the "cut" trace, hence the size is smaller and easy to share

• Passing orientation - is when DIR output of TUSB321 will be high (default value)
• Failing orientation – when DIR output of TUSB321 will be low

let me know if you need more trace

Thanks for the strong support

Hi Alder,

Thanks for the traces, I will review and get back to you.

Hi Alder,

while I am debugging the trace, are you able to try passing the functional tests using a TUSB321 EVM?

Hi Vishesh,

You are referring to TUSB542EVM ?

I checked, the combination not really same to ours (TUSB321 + TUSB1142).

1 quick check on the TUSB542EVM found the type C is connecting to device, and the type B is to Host. for our case, we need the type C to host. Is Ti has this evaluation board?

Thanks,
Best regards,
Alder

Hi Alder,

Apologies, I meant the TUSB320 EVM. This EVM is used for the TUSB321 and TUSB320. 

I would like the setup to be as follows:

Is this possible? 

Also can you share the schematic of teh system?

Hi Vishesh,

Looked at TUSB320EVM only has CC controller, do not have mux, not really helpful i think.

Schematic had been downloaded to the link you share.

Thanks,
Best regards,

Alder

Hi Alder,

The test failing do not require the USB signal connections:

Additionally, all these tests are sink tests. 

The TUSB320 EVM passes the USB signal across, but the tests that are failing are sink level CC tests. I believe the EVM can be used here to replicate the tests on a known good board.

Hi Alder,

I would still like more information at what step we fail. I'm not sure where the failures are in the test we do not pass. This makes it more difficult to debug. Could you provide that information?

The TUSB321 should have the same functionality in the normal and flip orientations so its odd that one side passes while the other side fails.

Hi Vishesh,

From my observation, the default orientation pass and when flip orientation fail might due to the debounce time, the communication missed during the flip was delay due to debounce time (123ms) ?

Thanks,

Best regards,

Alder

Hi Alder,

I'm not sure the issue has to do with debounce time. as the 123ms is well within USB-C specification

How exactly are we running this test?

Hi Vishesh,

You  mention TD 4.10.1/2/3 are sink test, should not require USB signal connection (TUSB1142) ?

You mean no need RXdetect etc?

Hi Alder,

Tests 4.10.1/2/3 are testing the power and CC negotiation. This does not require the data links. 

Hi Vishesh,

It is strange that this is failed then.

From what i hear, the test need data link for current capabilities via package. I need to read more on the specification or if you have it handy, can you point this out ?

Thanks,
Best regards,
Alder

Here is the link to the spec: https://www.usb.org/sites/default/files/USB%20Type%20C%20Functional%20Test%20Specification%202024%2003%2003.pdf

Were you able to test with the EVM?

Thank you for the spec... From the spec, it enumerates to USB3.1 speed. For our case, it doesn't. That is why it is a combination of TUSB321 + TUSB1142.

I do not have the EVM but i think this should be different behavior compare to ours

Hi Alder,

This is new information. Just to clarify, we enumerate at USB3.1 speed in normal orientation and USB2.0 in flip orientation? 

Can you confirm the TUSB1142 is properly switching the paths? How is the flip pin connected on the TUSB1142?

Hi Vishesh,

This is new information. Just to clarify, we enumerate at USB3.1 speed in normal orientation and USB2.0 in flip orientation? 

--> Yes. Since it enumerate to USB2.0, it is fail for our testing.

Can you confirm the TUSB1142 is properly switching the paths?

--> Yes. TUSB1142 flip is working. it is working on "HOST" mode (since we are DRP). It is also working on normal functioning test

How is the flip pin connected on the TUSB1142?

--> From TUSB321. You may see this connection at schematic that i share you in the same link.

Thanks,
Best regards,
Alder

Alder Lim said:

Yes. TUSB1142 flip is working. it is working on "HOST" mode (since we are DRP). It is also working on normal functioning test

In functional test we enumerate at USB3.x speed?

Alder Lim said:

--> Yes. Since it enumerate to USB2.0, it is fail for our testing.

What is the difference between this test setup and the functional test setup? Are different cables used?

In functional test we enumerate at USB3.x speed?

--> Enumerate at USB3.1 on non-flip and USB2.0 on flip side

What is the difference between this test setup and the functional test setup? Are different cables used?

--> Both is the same, just the Host is different, normal functional use Host PC etc... same cable used

Hi Alder, 

Thanks for clarifying. Based off of the information provided it seems that the issue is that the TUSB1042 is not properly muxing the signals. This can be due to three main reasons. 

1) The TUSB321 is not properly detecting flip: This can be tested by probing the DIR pin during normal and flip orientations. 

2) The TUSB1142 is not properly receiving the flip signal. Probe the FLIP/SCL pin on the part to see if its properly set.

3) The TUSB1142 is not properly setting the MUX paths. Test this by doing a continuity test through the following paths:

sorry i check back previous reply, i overlooked

In functional test we enumerate at USB3.x speed?

--> Both side work well

In USB test we enumerate at USB3.x speed?

--> Enumerate at USB3.1 on non-flip and USB2.0 on flip side

Hi Alder,

In this case, the issue is most likely stemming from the test being performed. Can you send a detailed test setup with names of all hosts and devices? We know that the functional works, so there is an issue when using the 

Alder Lim said:

Both is the same, just the Host is different, normal functional use Host PC etc... same cable used

If functional works on one host but fails on the other, we may need to test functional on the second host as well. We haven't observed an issue like this before with the TUSB321 in all its years of release, so I find it hard to believe that this is a TUSB321 issue

Hi Vishesh,

What i refer to is normal functional test pass.

The failed in only on the USB 3 Compliance test 4.10.1 / 4.10.2 / 4.10.3 with Ellisys (Host). 

The functional wording confusing over here, let me explain further: -

Normal functional test refer to not compliance test, any host that connect to our DUT is functioning well.

The failure here i am refer to USB 3 Compliance test 4.10.1 / 4.10.2 / 4.10.3, also with Lecroy as a host also pass here, same setup, just change to Ellisys and it failed

Hi Alder,

Could this issue be associated with the ellisys compliance test? . We haven't validated with an ellisys system before, so I don't think I can help much here. Especially since we have the Lecroy setup working