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).
I comment to fix my previous mistake, it should be “CONFIG_USB_SERIAL_SIMPLE=m” instead of “USB_SERIAL_SIMPLE=m”