We have developed (with the help of a external part) a custom carrier board which has one usb-c port for uart debug serial communication and another for flashing & normal usage.
It works well for flashing images but I have not been able to get it to switch to host usage. From my limited understanding of the schematics it should be possible for it to switch between host and device usage during runtime so what am I doing wrong?
I’ve attached my usb device tree settings as well as the schematics of the MUX for the device/host usage.
Thanks in advance,
Fredrik
tegra234-p3768-0000.txt (4.5 KB)
Please also provide the jetson SOM side connection.
Also, your device tree won’t achieve the OTG function by just such content…
usb2-0 {
mode = "otg";
vbus-supply = <&vdd_5v0_sys>;
status = "okay";
usb-role-switch;
};
This part basically tells “wants to support otg”.
How to achieve is totally not mentioned.
Yes sorry here is the SOM side connection.
Oh alright, do you have any tips on what I need to add?
The resolution of this picture is not clear enough to read.
Sorry, is this better?
Schematic_v1_0_1-pages.pdf (64.6 KB)
Want to clarify some points here
Please be aware that we don’t know how is the exact mechanism of this type C controller is expected here.
This is something that should check with IC vendor.
I saw there is “VBUS_DET” and “ID” on it.
Does it expect Jetson GPIOs to be VBUS_DET and ID pins for it?
BTW, not sure if anything missing there. Shouldn’t your USB0_D_N signal be present in above type C controller too?
Here is more context from how it’s built. I’m not quite sure how to answer your previous questions without speaking to the external partner who designed it but maybe this will clarify it to some extent..
Schematic_v1_0_1-4.pdf (57.6 KB)
Please go ahead and discuss this with your partner first.
You need to figure out how your custom board hardware works first. For example, what signal they expect Jetson to do with it. Otherwise we won’t be able to tell how to write device tree.
Sounds reasonable, thank you. Will try to get in contact with them tomorrow and get back to you.
Just to update and make sure thread isn’t closed, they are currently looking into it.
Hi again,
I attached the relevant device tree file for this.
We have made a patch in which the ID pin of the controller goes to GPIO01.
usb_dt_file.txt (5.7 KB)
I have made sure it works (goes low when device connected, otherwise high). This was done by looking at “cat /sys/class/usb_role/usb2-0-role-switch/role" and see the role is outputted. But even if that says it has role set as host when I connect the device I get this in dmesg:
[ 47.621739] tegra-xusb 3610000.usb: xHCI host controller not responding, assume dead
[ 47.621743] CPU:0, Error: cbb-fabric@0x13a00000, irq=176
[ 47.621756] **************************************
[ 47.621756] tegra-xusb 3610000.usb: HC died; cleaning up
[ 47.621759] CPU:0, Error:cbb-fabric, Errmon:2
[ 47.621767] Error Code : PWRDOWN_ERR
[ 47.621777]
[ 47.621779] Error Code : PWRDOWN_ERR
[ 47.621781] MASTER_ID : CCPLEX
[ 47.621783] Address : 0x3610420
[ 47.621785] Cache : 0x1 – Bufferable
[ 47.621788] Protection : 0x2 – Unprivileged, Non-Secure, Data Access
[ 47.621792] Access_Type : Read
[ 47.621794] Access_ID : 0x17
[ 47.621796] Fabric : cbb-fabric
[ 47.621798] Slave_Id : 0x22
[ 47.621800] Burst_length : 0x0
[ 47.621802] Burst_type : 0x1
[ 47.621803] Beat_size : 0x2
[ 47.621805] VQC : 0x0
[ 47.621807] GRPSEC : 0x7e
[ 47.621808] FALCONSEC : 0x0
[ 47.621811] Slave : AXI2APB_16
[ 47.621814] **************************************
[ 47.621841] WARNING: CPU: 0 PID: 1899 at drivers/soc/tegra/cbb/tegra234-cbb.c:608 tegra234_cbb_isr+0x144/0x190
[ 47.622253] —[ end trace 427927b3991bc4dc ]—
Hi,
I would say you should clarify what is your hardware design now… You could not just give me a dts and ask if I could help.
Your hardware is just over there on the other side of this planet… if you don’t clarify how that design looks like, then others won’t know what you are doing…
Also, ID pin alone should not be a valid design… A true USB role switch has to be with ID pin + Vbus detection pin together…
Hello,
I provided the schematics of the SOM + the USB parts of the board earlier in this thread.
Basically USB0 and USBSS_1 go from the SOM to the USB controller (HD3SS3220RNHR). Then from the controller the ID pin has been drawn to the SOM as GPIO01 (which is what I reference in the dts file). This part about the ID pin is not included in the schematics because it has been done as a patch and isn’t included in the official schematics. I looked at this table for reference:
In which ID=0, VBUS=0 should be host and ID=1,VBUS=0 should be device. Which is what I also read out from the software with " cat /sys/class/usb_role/usb2-0-role-switch/role". But even though that role says host I don’t get any connection to the connected device, meaning no message in dmesg about detecting an usb device, just the error I mentioned in my last message. The message also only shows up the first time I connect a device after starting up the jetson and then after that nothing more shows up in dmesg related to USB. If I reboot the jetson and then connect a device again I get the same error.
Please tell me if there’s any information you’re missing and I’ll do my best to provide it.
So is this a type C controller design or something else…?
We expect vbus_det and ID pin should be both present to fully achieve the case happened on the truth table.
Also, the only “one pin” case that supported is “no ID pin but only vbus_det” case. That design could achieve “device mode only” situation. But “only ID pin” case won’t achieve that…
Yes it’s a type C controller design.
Okay we will look into how to draw the vbus_det to a gpio as well. Just thought it’s strange how the usb_role stated from cat /sys/class/usb_role/usb2-0-role-switch/roleis correct but maybe there’s something else in the background that needs to have a connection to vbus for it to actually connect to the device?
Hi,
Just want to clarify.
What you are talking about here is actually a USB OTG port design concept.
For example, it is very common to have “Vbus Det pin only but no ID pin” case but there is no opposite situation.
Lacking of Vbus Det could not make a USB port work correctly.
If you want some quick answer behind this, then using some AI agents might help answer that quickly.
