Hi
sorry to bother but it seems that on Orin with latest jetpack release installed a week ago, no ttyUSB* device is creating when plugging either a CH340 chip controller or a YDLIDAR. Cannot bind to any usb port. I really tried everything. Any suggestions?
Many thanks
If you monitor “dmesg --follow”, and then plug in the device, what do you see in the logs as a result of the plug-in?
an update
removing sudo apt remove brltty service worked for the lidar device. Still no luck with the CH340 we are testing different boards.
why brltty is taking over the rules of usb? to read for blinds person when a usb devices is connected by doing sound or something to help him to detect the fact that a usb is being inserted in the jetson?
with the ch340 my user is in the tty and dialout group and i gave permission to
sudo chmod g=rw /dev/ttyAMA0
output from dmesg is
[ 295.804719] usb 1-4.2: new full-speed USB device number 9 using tegra-xusb
and nothing else related to the plugged in board. The board works on window.
many thanks
I can’t answer for brltty, but it is likely it has added a udev rule to rename or find a device specific to its software. This would make that device appear to change or go away for other software that does not expect a rename.
Your dmesg indicates the device is detected by USB, and its information broadcast to hot plug, but no hot plug driver took ownership of the device. Do you have a URL to the specifications and information on your specific device? With the device plugged in, do you see the one corresponding to your device via “lsusb”? If so, can you post that line?
thanks for your answer.
command lsusb detect the device:
Bus 001 Device 012: ID 1a86:7523 QinHeng Electronics CH340 serial converter
i also added in the udev rules the following:
SUBSYSTEM==“tty”, GROUP=“tty,dialout”. MODE=“0660”
SUBSYSTEMS==“usb”, ATTRS{idProduct}==“7523”, ATTRS{idVendor}==“1a86”, SYMLINK+=“arduino”
I am not a linux developer so i am sorry if the rule in not correct any help in make it right, if that might be the issue, is appreciated.
we see it happening always with the CH340 usb converter. we tried a completely different boat that has the same converter and happened as well.
even if we have version 5.12 i tried to force install the kernel module THIS from jetsonhacks. their version is 4.56 but no changes.
many thanks again for your help.
You shouldn’t be modifying the group tty. This gets assigned automatically if and only if that device is used as a console. Login software controls this, and you are trying to open all logins to be read by anyone. Probably this wouldn’t be enough, but seeing tty definitely means you have a conflict of two programs struggling to control the same device. The proper method to work with this is to not adjust any group tty, and to then remove or alter configuration to have that device not set to run a terminal. Any time you see group tty, and if you try to use that device, then you have a conflict and likely corruption as two programs respond simultaneously to the same device.
You could remove the tty from your udev rule, but I am still suspicious that the rule is a problem. Specifically sym linking though is likely a good idea since it leaves the original intact. The symbolic link takes on the same permissions as the device it links to. If that device it links to exists with group dialout, you have success; if the device linked to has group tty, then you shouldn’t be doing this without first disabling getty/agetty on that port (getty is the login software…short for “get tty”).
Never manually chmod group or permissions for a device special file. This is not a real file, it is a driver in RAM pretending to be a file (a “device special file”). You should add yourself to group “dialout”, or else use root authority (“sudo”). If your user name is “nvidia”, then you can add user “nvidia” to group “dialout” like this:
sudo usermod -aG dialout nvidia
(after that you don’t need to do anything to use group dialout devices)
Also keep in mind that if you intercept that device with your own udev rule, it is possible that a driver won’t see this port. The following indicates USB is working correct, but does not say if a driver bound to it:
[ 295.804719] usb 1-4.2: new full-speed USB device number 9 using tegra-xusb
Does your udev rule result in the existence of the symbolic link you added the rule to?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.