Access to a USB serial device after a Jetson Nano is repowered

I have written code to ID and take an image of ‘detections’ identified using ssd-mobilenet etc. It will do a frame grab and save the image with GPS coordinates. I need this program to run automatically. The problem I have is that the USB serial port when the system is powered off and back on again (if it’s simply rebooted it is OK) the GPS device is not accessible until I run “chmod -R user:group /dev/gps0” the program then runs correctly.
Does anyone have a work around for this problem? That is a serial device not being available after the unit is re-powered (not after re-boot)?

What are the permissions when working, and when failing, for “/dev/gps0”? Run command “ls -l /dev/gps0” when it is correct and when it is not correct.

Btw, you would have to expect to destroy parts of the filesystem if you just power it off and then on. The Jetson is no different than a desktop PC in this respect…imagine yanking the power cord from the wall socket on the running desktop PC, and then plugging it back in. I don’t know if this is what you mean by the power off/on, but if it is, then something new needs to be figured out to not damage the filesystem. Assuming this really is a power off/on without a proper shutdown, what is the reason for this?

FYI, the journal on the ext4 can reverse a certain amount of damage, but the repair it performs also implies lost file content.

When I do an ls -l /dev/gps0 >>/tmp/junk.txt in the script. When I run it manually it returns
lrwxrwxrwx 1 root root 7 Jan 30 17:32 /dev/gps0 → ttyACM0
When I run it in systemctl on when it reboots it returns nothing… I changed the port I access to ttyACM0 … so
ls -l /dev/ttyACM0 return
crw-rw---- 1 root dialout 166, 0 Feb 4 17:19 /dev/ttyACM0
when I manually run it and a blank when I run it in the script…

It appears that I need to run two different scripts on reboot. One that runs as root that sets the permissions and a second one that subsequently runs script as a user. The issue of the permissions changing depending upon reboot or power-on restart I was not able to reproduce so that was a bit of a ‘furphy’ … it’s not available when its either rebooted or powered on … Any ideas or examples I have tried crontab -e and i am not able to get that script running … sigh …

I’m not certain of all that is going on, but the change in ownership for gps0 being “root root” means it could only be accessed with sudo at that point. The actual file name “gps0” would be due to the driver and/or a udev entry ("udev" will trigger upon certain devices being created, and if there is a matching rule, then some common operations usually occur, e.g., changing ownership or name of the device special file). However, this is a symbolic link, and such a link is created by udev, so the original ttyACM0 was created by the driver, and udev created the gps0 symbolic link pointing at ttyACM0.

The ttyACM0 is the driver of that chipset. Because ttyACM0 is ownership “root dialout” anyone who is in group “dialout” could access the device ttyACM0 directly. The symbolic link group is not “dialout”, so I suspect using the “gps0” link won’t work for a regular user even if the user is in group “dialout”.

My first recommendation is to add your regular user to group “dialout”. This means that user would no longer need sudo if accessing “/dev/ttyACM0” (I am assuming your user account name is “username” in this example):
sudo usermod -aG dialout username

Do you really need to access this as “/dev/gps0”? If so, then you would want to set up a udev entry to do this correctly rather than using chmod or chown. It is in fact likely that gps0 is already created by a udev entry (but perhaps not). If you don’t already have the command “tree” available, then add this with “sudo apt-get install tree”, and show what you see from:
tree /etc/udev/rules.d
(one of those files likely creates gps0, and might be modified to also set permissions)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.