Hello!
Could you please confirm or refute the fact that any USB2.0 can be configured as a ‘peripheral’?
The TRM and datasheet of the ORIN NX are contradicting each other.
TRM:
Please state clearly: “Yes all of them can be in peripheral mode” or “No, only USB2-0 can be in peripheral mode” or how is it de facto.
Please state for which ORIN modules is it valid?
Thank you
You can pick any of the USB2 port as device mode. But only one device mode port could run there at same time.
For example, you could configured 2x USB2 ports as device mode. But when runtime, only one of them could be in use. If you want to use another, you have to unplug the first one.
OK, thank you for the answer.
The intention is to use usb2-2 as a serial to communicate with a Host PC (Linux).
I modified the DT so that usb2-2 is in peripheral mode. (usb-role-switch property also present). I disabled l4t usb mode service, and there is no other port acting as a device or bound to anything in this sense (also confirmed that there is only one directory in ls /sys/kernel/config/usb_gadget/)
At runtime I made the necessary configs for it, gadget is bound to the UDC, using the ACM function. Function is present (acm.usb0) and the UDC is set. On the target all seems all right. Even /dev/ttyGS0 is created.
However, the Host PC fails to enumerate it. Nothing happens when plugging the cable to the host.
Any ideas what else I can explore? Could it be related to VBUS Det?
You could use our example (e.g. l4t usb mode service) to test the USB peripheral mode first.
If even that one is not working, then we can review the device tree and hardware.
Hi,
I reactivated the nv-l4t-usb-mode service. But the behavior is the same. No enumeration on the host. Here is the DT related to usb2-2 and xudc (decompiled on the running system JP5.1.3):
...
xusb_padctl@3520000 {
...
pads {
usb2 {
clocks = <0x02 0xa5>;
clock-names = "trk";
lanes {
...
usb2-2 {
status = "okay";
#phy-cells = <0x00>;
nvidia,function = "xusb";
phandle = <0x2be>;
};
...
ports {
...
usb2-2 {
status = "okay";
mode = "peripheral";
vbus-supply = <0x2b6>;
usb-role-switch;
};
...
xudc@3550000 {
compatible = "nvidia,tegra234-xudc";
reg = <0x00 0x3550000 0x00 0x8000 0x00 0x3558000 0x00 0x8000>;
reg-names = "base\0fpci";
interrupts = <0x00 0xa6 0x04>;
clocks = <0x02 0x109 0x02 0x115 0x02 0x113 0x02 0x110>;
clock-names = "dev\0ss\0ss_src\0fs_src";
power-domains = <0x02 0x0b 0x02 0x0a 0x02 0x0c>;
power-domain-names = "dev\0ss\0host";
nvidia,xusb-padctl = <0x2b9>;
iommus = <0x56 0x0f>;
dma-coherent;
status = "okay";
charger-detector = <0x2bb>;
avdd-usb-supply = <0x2b5>;
phys = <0x2be>;
phy-names = "usb2-2";
phandle = <0x469>;
};
...
Char dev is created, functions present, but no enumeration on the host PC.
I tried it also for usb2-0 with the same results. Although flashing works perfectly. But recovery mode is soemthing else and only for usb2-0.
It seems that at runtime both usb2-0 and usb2-2 do not act as device at all.
So, apparently the role in /sys/class/usb_role/usb2-2-role-switchwas none none.
Echo-ing device manually ,triggered the enumeration on the host.
What could cause this being none? I still have reason to believe that this is due to missing VBUS_DET.
I don’t know if I can help, but I will ask some questions. In all cases, monitor “dmesg --follow” on the host PC and note any logs occurring as a result of plugging in the Jetson to the host PC’s USB.
lsusb -tv” output? You would need to see what the output is prior to plugging in the Jetson, and then compare branches (that lsusb is a tree view) to see what has changed.Just for the purpose of concept, if the host PC has any log (device mode) of the plug-in event, then hot plug is detected. If there is some description in that log as to type of device, vendor ID, so on, then some information about the type of device has been detected. If the host PC has driver software capable of working with that type, then a driver will try to load on the host PC; this is what creates any initial “/dev” file. If there is a udev rule, then the “/dev” file might be modified, e.g., it might have a name change or have a symbolic link added to categorize the device in more than one way. Also, one device mode port can show more than one device or more than one interface to a single device.
You should share the schematic and full DT.
The behavior of role is partially decided by hardware. So checking vbus and id pin status are also necessary.
I agree. But, I do not see any VBUS pin for USB2-2 in the datasheet/documents. The only VBUS detect is the for USB2-0 which is Pin-87 (GPIO00).
We do not have any vbus pin for usb2-2 in our schematic.
What pin is this on the module?
Hi,
I am not sure what you are trying to tell here. Vbus-det pin is needed for the device mode to work fine.
If you don’t have it on usb2-2 port, then device mode may have problem.
I am trying to make you tell me what is the VBUS-det PIN number on the ORIN module associated to USB2-2. Because the documentation does not include this pin in the pinout list of the module.
You could use any GPIO for it and assign it to the device tree. There is no “you must use GPIO #xx for vbus-det” rule here.
Thank you.
It was like nothing was there. Nothing whatsoever on the host.
But now I got it where the problem was. Thanks for your input. As a workout I manually echoed device into the sysfs role. Then everything worked. Although we need to add the VBUS capability at the hardware level, as right now it is missing.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.