I’m integrating a Wifi/BT m.2 module on the Jetson Nano. I’ve recompiled the kernel, compiled backport modules for the radio module, and got all this flashed to the target.
The module has a USB (Wifi) / UART (Bluetooth) interface. The Wifi interface comes up without issue. It’s the Bluetooth side when running btattach it rarely attaches:
sudo btattach -B /dev/ttyTHS2 -P h4 -S 3000000 &
If I first do a sudo su, then do the attach it works every time.
btattach -B /dev/ttyTHS2 -P h4 -S 3000000 &
At first I thought maybe hardware flow was not on, but I can’t tell. Can someone tell me if hardware flow is on by default for /dev/ttyTHS2?
If hardware flow is on why would this work every time under sudo su, but not sudo?
There should be almost no difference. If you use “sudo ...something...”, and compare it to “sudo su”, then the difference is not in permissions, but is instead a difference in environment variables. The “sudo ...something...” can inherit some of the original user’s environment. If in both cases you ran the command “printenv”, then you would find some of those variables differ.
The real question is what do you see from “ls -l /dev/ttyTHS2”? It should have a “group” assigned to it, and if it has serial console, then the group will be “tty”, whereas a serial UART which is open for you to use would be group “dialout”. Rather than using sudo (or sudo su) you should add your regular user to supplemental group “dialout” (assumes it is group dialout). Example if the user name is “someone”: sudo -aG dialout someone
After that your regular user should be able to use the UART. Not sure why your environment for sudo and sudo su would cause a failure, but consider that environment might cause different files to be in a path in different order. Do you get this error if you add your regular user to group dialout, and then try to run the command without sudo?