Hey all,
I’m having some trouble getting the TX2 to communicate with another device using serial communication, and am looking for some help.
Some background for context:
I’ve written a logging utility in Java that takes information the device sends over serial and writes it to a .csv file for later analysis. The utility is written in pure Java code, except for the part that manages the serial communication. For that, I’m using the jSerialComm library, which is platform independent.
The utility was originally developed on a raspberryPi, and is working perfectly there! I only get problems when I try to run the utility on the Jetson TX2. Specifically, I can’t find the path to the device file of the device I’m communicating with on the Jetson.
When I plug the device into the raspberryPi, a new folder appears in the “/dev/” directory called “serial”, and I can see the “file representation” of the device in that folder. The full path is “/dev/serial/by-id/deviceName”. When I give this path to the program running on the raspberryPi, there are no issues.
When I plug the same device into the jetson, I don’t see the “serial” folder show up in the “/dev/” directory, and I’m not sure where else to look for the device file.
Does anyone know why this folder would show up on the pi, but not the jetson? Does anyone know what I can do to get this folder, or an equivalent to appear on the jetson?
Is it correct that this is a USB device and you are connecting the USB end to the Jetson? If so, what do you see if you monitor “dmesg --follow”, and then connect the device?
Or are you using the integrated serial devices?
Just a heads up, it is the driver itself which creates the serial device in “/dev”. The initial appears of a file there is due to this driver, but it is possible that the udev system can rename this. On a desktop PC it would be typical for udev to create other devices beyond the “/dev/ttyS#” device. udev is designed to be able to take rules on various devices and provide alternate names or renames. In the case of generic serial devices you will only see something like “/dev/ttyS1” (the number may be quite different on a Jetson, more details would need to be known…there are already some serial devices and the starting device name for an extra device would be altered because of that).
In the case of an embedded system like a TX2 the extra udev packages changing device naming probably won’t exist. In part that is because the integrated devices are generally configured via device tree, and there is no need for a udev system. That “dmesg --follow” log will say a lot, e.g., perhaps the name is just not what you expect, or perhaps you need a driver which is missing.
Yes, you’re correct that this is a USB device and I’m connecting the USB end to the jetson.
When I run “dmesg --follow” and then connect the device, I get the following output:
usb 1-2: new full-speed USB device number 3 using xhci-tegra
usb 1-2: New USB device found, idVendor=20d2, idProduct=5740
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product:
usb 1-2: Manufacturer:
usb 1-2: SerialNumber:
usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
How should I interpret this?
This says USB has done its job and is functioning correctly. The part which happens based on your log is that USB announces the device description, and that a driver which recognizes it belongs to this device will load and take ownership. No driver claimed ownership, so basically you need the driver.
Keep in mind that USB is just a data pipe which announces devices. USB does not in itself provide drivers. There are some standard class drivers which all USB systems have, and although those drivers are standardized and everything has those drivers, the drivers are still actually a separate entity from USB itself. Many devices “just work” because they use a generic driver. Yours is apparently not standard.
Unfortunately I couldn’t find the vendor ID 20d2, so I can’t look it up. Apparently this is a purely custom device not using general USB class drivers. The manufacturer will need to provide drivers, or at least say which standard kernel driver is used. If the manufacturer and product ID were matched to an actual manufacturer and device, then research can be performed on what driver is required.