【xavier】USB serial port can not be recognized

What is the exact serial cable (a model number would help)? Is this cable plugged in (USB side) to the Xavier?

@ yyjqr789
What if you use usb-C [(J512) AGX recovery port] to USB-A [at host PC] connection?
it should create /dev/ttyACM0 device that could be accessed e.g.

sudo apt install picocom -y
sudo picocom /dev/ttyACM0

This is some dmesg info . PL2303GT chip from Taiwan. usb side is plugged in Xavier, another side is connected to GNSS Device.

[16129.625652] usb 1-2.2: New USB device found, idVendor=046d, idProduct=c534
[16129.625668] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[16129.625675] usb 1-2.2: Product: USB Receiver
[16129.625680] usb 1-2.2: Manufacturer: Logitech
[16129.630377] input: Logitech USB Receiver as /devices/3610000.xhci/usb1/1-2/1-2.2/1-2.2:1.0/0003:046D:C534.0003/input/input8
[16129.691843] hid-generic 0003:046D:C534.0003: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-3610000.xhci-2.2/input0
[16129.695729] input: Logitech USB Receiver as /devices/3610000.xhci/usb1/1-2/1-2.2/1-2.2:1.1/0003:046D:C534.0004/input/input9
[16129.755021] hid-generic 0003:046D:C534.0004: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-3610000.xhci-2.2/input1
[16129.858023] usb 1-2.3: new full-speed USB device number 8 using tegra-xusb
[16129.880332] usb 1-2.3: New USB device found, idVendor=067b, idProduct=23c3
[16129.880347] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[16129.880355] usb 1-2.3: Product: USB-Serial Controller
[16129.880361] usb 1-2.3: Manufacturer: Prolific Technology Inc.
[16129.880367] usb 1-2.3: SerialNumber: BKCNb19C116
[16130.046262] usb 2-1: usb_suspend_both: status 0
[16130.047526] usb usb2: usb_suspend_both: status 0
[16130.270143] usb 2-1: usb_suspend_both: status 0
[16130.270572] usb usb2: usb_suspend_both: status 0
[16130.446269] usb 2-1: usb_suspend_both: status 0

Thanks.Recently, I just use Xavier to connect to a GNSS Device with RS232-USB cable, not communicate with PC.

Is this a hard wired custom solution, or is this just a USB cable you can unplug and replug? Because the USB side is connected to the Jetson it means the Jetson needs the driver, but if this is part of a custom hardware solution the requirements may differ versus if this is just a USB plug being inserted into a known working USB port (I am guessing it is, but want to confirm).

This part of the log shows USB is correctly functioning, but does not mention a driver:

USB is a “hot plug” system, and when the device reports its specs, USB broadcasts what the device is. If a driver can handle the broadcast device, then that driver would take ownership of the device. I see the broadcast, but I do not see a driver taking ownership (the driver is actually separate from USB other than talking through USB).

For reference, I found this information about the driver:
https://patchwork.kernel.org/project/linux-usb/patch/20190213123000.4656-1-charlesyeh522@gmail.com/

I am not positive, but I believe this kernel config enables the driver:
USB_SERIAL_PL2303

On your Jetson what do you see from:
zcat /proc/config.gz | grep -i USB_SERIAL_PL2303
(I ask because I did not see a log of the creation of a UART device in “/dev”, but a TX2 I looked at had this configured as a module by default)

Also, with this device plugged in, what do you see from “lsmod”?

Incidentally, I don’t think there is any USB suspend issue from the above, but it is rather common for low power or suspend modes of USB devices to break. Even if this was a problem you’d still have the “/dev/tty...something serial...”, and we need to identify the device special file to continue (or identify that the driver failed to load and thus there is no device special file).

Before I use this cable, shown as picture. config has PL2303,but doesn’t have a ttyUSB device . Now I use a FTDI chip RS232-USB cable ,it 's OK.The problem I will continue to check ,but I think it’s more about the driver or the PL2303 chip.

ai@ai-desktop:~ zcat /proc/config.gz | grep -i USB_SERIAL_PL2303 CONFIG_USB_SERIAL_PL2303=m ai@ai-desktop:~ lsmod
Module Size Used by
bnep 16562 2
fuse 103841 3
ftdi_sio 47837 1
zram 26166 8
u3v_drv 67021 1
mvUniversalForEthernet 201179 0
xt_tcpudp 4182 2
iptable_filter 2481 1
overlay 48691 0
spidev 13282 0
binfmt_misc 13103 1
userspace_alert 5665 0
nvgpu 1580772 41
bluedroid_pm 13912 0
ip_tables 19441 1 iptable_filter
x_tables 28951 3 ip_tables,iptable_filter,xt_tcpudp
ai@ai-desktop:~$ dmesg |grep ttyU*
[ 0.000000] Kernel command line: console=ttyTCU0,115200 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt tegra_fbmem=0x800000@0xa069d000 lut_mem=0x2008@0xa0698000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix=_b boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4
[ 0.001235] console [tty0] enabled
[ 1.729381] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 51, base_baud = 0) is a TEGRA_UART
[ 1.730875] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 52, base_baud = 0) is a TEGRA_UART
[ 1.731816] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 53, base_baud = 0) is a TEGRA_UART
[ 1.733077] console [ttyTCU0] enabled
[ 11.163659] usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB0

FTDI chipsets always seem to have a driver, and seem fairly standardized. The PL2303 would use a different driver, but if it is present, then upon plugin of the USB side you should see the name of the “/dev/tty*” created for this.

Note that it is the load of the driver for the serial UART (which only occurs after USB announces the device) which produces the file in “/dev”. Different drivers might use a different naming convention, and so I don’t know if your driver actually creates a “/dev/ttyUSB#”, or perhaps some other naming convention.

The zcat command seems to show you have the driver in module format. I see the module “ftdi_sio” is loaded, but don’t see anything which is for the PL2303…but if the PL2303 is an ftdi chipset sold under the PL2303 branding, then it may be that the ftdi_sio is actually the driver (but with some name changes). On the other hand, from what I can see, the PL2303 uses a different driver in the kernel source (not the FTDI driver).

If you run command “dmesg --follow”, and specifically watch this as you plug in the PL2303, what do you see? If it is something for “FTDI”, then things are going well; if not, then you may be missing a driver (and the “FTDI” log would be for a different UART).