TDA4APE-Q1: Questions about USB

Hi Mian,

Mian DENG said:

As I understand, USB0_DRVVBUS is used as an enable pin for VUBS power. Is my understanding correct? So I suppose USB0_DRVVBUS is necessary in our use case? Or can we just keep the VBUS power supply always enabled so that we don't need to control USB0_DRVVBUS?

Mian DENG said:

• As I understand, USB0_DRVVBUS is used as an enable pin for VUBS power. Is my understanding correct? So I suppose USB0_DRVVBUS is necessary in our use case? Or can we just keep the VBUS power supply always enabled so that we don't need to control USB0_DRVVBUS?
• From datasheet, only 3 pins can be used as USB0_DRVVBUS as shown below. Can we use an ordinary GPIO other than the 3 pins as VBUS power enable pin? If so, how should I do the configuration because I did not find the loacation in the driver code where the USB0_DRVVBUS pin is controlled. 

I belive DRVVBUS is mandatory for drving the VBUS .However, I have informed the USB hardware expert to double confrim on these queries.. Thanks in advance for your patience.

Mian DENG said:

We are using Type-C connector so we hope it supports reversible plugging. In TRM, it says lane 2 of SERDER0/4 are reveserved for USB Type-C lane swap functionality. But in kernel code, it says nothing about configuring lane 2 of SERDERS 0/4 for USB usage. So how should I configure it?

For enabling the lane swap feature, you can follow this FAQ.

[FAQ] J784S4XEVM: Enable USB3.0 functionality on lane 2 of TDA4VH - Processors forum - Processors - TI E2E support forums

Best Regards

Gokul Praveen

Hi Mian,

Mian DENG said:

Besides, the link says NOTE:After doing above changes USB will work in 2.0 mode only if you are using lane 3. Does this mean that if we want to take full advantage of lane swap feature, the USB only supports USB2.0 mode? 

That is a typo actually. Sorry for that. It is 3.0 mode , not 2.0.

Mian DENG said:

I don't quite understand why the patch in the link you provided removed the configuration related to typec-dir in the dts. Generally speaking, shouldn't the Type-C direction be determined based on the GPIO signal to trigger the lane switching action?

This device tree property is for dynamic or on-the-go lane swap switching feature which is not currently supported.

However, static lane-swap feature is supported and will not require these properies.

Regards

Gokul Praveen

Hi Gokul,

Do you mean that this patch merely supports SERDES0_LANE2 for USB 3.0 usage while USB3.0 features cannot be supported on both sides of Type-C connector since OTG lane swap is not supported currently?

In fact, after applying this patch, only the side which connects to SERDES0_LANE2 is recognized as USB3.0 device, and the side that connects to SERDES0_LANE3 is only recognized as USB 2.0 device.

By the way, I accidentally marked the question as resolved. Is there any way to undo this action?

B.R.

Mian

Hi Mian,

Mian DENG said:

Do you mean that this patch merely supports SERDES0_LANE2 for USB 3.0 usage while USB3.0 features cannot be supported on both sides of Type-C connector since OTG lane swap is not supported currently?

In fact, after applying this patch, only the side which connects to SERDES0_LANE2 is recognized as USB3.0 device, and the side that connects to SERDES0_LANE3 is only recognized as USB 2.0 device.

Can you share the SDK version you are using?

Mian DENG said:

By the way, I accidentally marked the question as resolved. Is there any way to undo this action?

Its fine, you will be able to post your queries here even if it is marked as resolved

Best Regards

Gokul Praveen

Hi Gokul,

I'm using SDK 11_01.

Best Regards

Mian

Hi Mian,

Apologies and sorry for the late reply.

I was able to reproduce the same on my end on TI J784S4 EVM where the side which connects to SERDES0_LANE2 is recognized as USB3.0 device, and the side that connects to SERDES0_LANE3 is only recognized as USB 2.0 device.

I have raised this bug internally(LCPD-45340) which will take some time to debug,

In the meanwhile , a workaround would be either to not use the lane swap feature or connect to the lane where USB3.0 is detected while lane swap feature is enabled.

Best Regards

Gokul Praveen

Hi Gokul,

Thank you for your reply. 

If you have any further information on this issue, please keep me informed.

Meanwhile, I have 2 additional findings.

First, the TRM says USB supports limited OTG2.0 and does not support OTG3.0 as shown in picture below. Does this mean the device can only work under 2.0 mode?

Second, in the documentation for the kernel device tree, there is an explanation about typec-dir-gpios, which only mentions lane 0 and lane 1. The corresponding driver code also only handles lane 0 and lane 1. Therefore, could the lane swap issue be due to missing logic?

Best Regards

Mian

HI Mian,

Mian DENG said:

If you have any further information on this issue, please keep me informed.

Sure Mian,

Mian DENG said:

Second, in the documentation for the kernel device tree, there is an explanation about typec-dir-gpios, which only mentions lane 0 and lane 1. The corresponding driver code also only handles lane 0 and lane 1. Therefore, could the lane swap issue be due to missing logic?

Actually,since this property is never included in the J784S4 evm device tree, it will always enter the else case in the driver code, which sets the swap bit for lane 2 and 3 . Hence, I dont think that is the issue, Mian. 

Mian DENG said:

First, the TRM says USB supports limited OTG2.0 and does not support OTG3.0 as shown in picture below. Does this mean the device can only work under 2.0 mode?

Actually USB2.0 /USB3.0 mode is different from OTG2.0/OTG3.0. OTG2.0 and OTG 3.0 refers to version numbers of OTG actuall(ie: version 2.0 and version 3.0)   

Best Regards

Gokul Praveen

Hi Mian,

can you restore the type-C orientation detect feature in the lines of code that has been removed following the FAQ?

-&serdes_wiz0 {
- typec-dir-gpios = <&wkup_gpio0 28 GPIO_ACTIVE_HIGH>;
- typec-dir-debounce-ms = <700>; /* TUSB321, tCCB_DEFAULT 133 ms */
-};

This should enable the type-C orientation detection and connect the SERDES lane 2 (or lane 3) to USB3.0. 

Hi,

If I restore the type-C orientation conf which is not included by default in the SDK I'm using in my kernel device device tree, the USB device will not probe with success. The device tree fragment and log are shown in the following pcitures.

Besides, as I mentiond in dusscution above, the driver code does not seem to deal with lane 2/3 swap with typec-dir-gpio. Can you confirm if this works?

Best Regards.

Do you use an i2c expander to control the typeC cable detection and orientation or use the GPIO? could you check if its the right address / matching your schematic? 

Mian DENG said:

he device tree fragment and log are shown in the following pcitures.

could you try this for one lane (2, and 3) each? 

&serdes0 {
status = "okay";

// lane 2 for swapped orientation
serdes0_usb_link: phy@2 {
bootph-all;
reg = <2>;
cdns,num-lanes = <1>; // Single lane
#phy-cells = <0>;
cdns,phy-type = <PHY_TYPE_USB3>;
resets = <&serdes_wiz0 3>;
};

// lane 3 for normal orientation
serdes0_usb_link_alt: phy@3 {
bootph-all;
reg = <3>;
cdns,num-lanes = <1>; // Single lane
#phy-cells = <0>;
cdns,phy-type = <PHY_TYPE_USB3>;
resets = <&serdes_wiz0 4>;
};
};

 Gokul Praveen , Siddharth Vadapalli do you know about the driver code he is referring to? 

Hi Shreyas,

ShreyasRao said:

 Gokul Praveen , Siddharth Vadapalli do you know about the driver code he is referring to? 

The code snapshot in the below link is the one he is referring to.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1600884/tda4ape-q1-questions-about-usb#:~:text=Actually%2Csince,issue%2C%20Mian%2E

Best Regards

Gokul Praveen

Hi,

Yes, I'm using an I2C IO expander to detect the typec orientation, to be more specific, a TCA9539. And I've checked that the configuration of the expander is right.

If configuring Lane 2/3 seperately as single lane, which should I choose as PHY for usb0?

Well, I've tried both. If I use <&serdes0_usb_link>, i.e. Lane 2, the USB works with one side as 3.0 standard. But if I use <&serdes0_usb_link_alt>, the USB device probe fails with the same Timeout error as posted above.

Do you have any further suggestion on this issue?

Best Regards

It somehow seems to me that the orientation may not be detecting correctly, since one side is working at USB3.0, but other side is USB2.0.

Did the schematic reviewed already with TI?  

Gokul Praveen , Siddharth Vadapalli , any other ideas on the s/w that needs to be tried on this issue? 

Hi,

The schematic has not been reviewed by TI. But I can post the related part below.

Best Regards.

Mian DENG said:

Yes, I'm using an I2C IO expander to detect the typec orientation, to be more specific, a TCA9539. And I've checked that the configuration of the expander is right.

Mian,

You would need to determine if your cable detection logic is detecting the cable flip correctly, if yes, then see if the s.w is configured correctly to detect that cable flip and switch the SERDES lanes appropriately to configure the USB3.0 mode.

The SERDES TX lanes on our EVM have 0.22uF AC coupling caps. Vbus detection logic, Vbus caps, cable detection logic some questions are there which I can request for review. 

Mian,

Are you able to probe the USB_DIR pin to see if it can change direction (H to L/ L to H)when the plug is reversed?

This will tell if the orientation logic is correct or not working. If it is not switching then it needs to be fixed, if it switches, then that signal should be implemented in s.w to change the SERDES lanes to support USB3.0

Hi,

The current hardware can detect changes in the insertion direction of the Type-C connector. This can be monitored either by measuring the voltage level of the USB_DIR pin with a voltmeter or by reading the GPIO value.

Best Regards.

Mian,

Sorry for the late reply. Since the detection is being done correctly about the insertion and the polarity of the cable, it seems that the h/w is behaving correctly.

It now seems this is a s/w code change / analysis needed to ensure that the USB_DIR is incorporated and the lanes are swapped accordingly. 

Hi Mian and shreyas,

ShreyasRao said:

It now seems this is a s/w code change / analysis needed to ensure that the USB_DIR is incorporated and the lanes are swapped accordingly. 

I have raised this bug internally(LCPD-45340).

Best Regards

Gokul Praveen