Issue with Serial Communication on Jetson Xavier NX When Launched via Systemd/Cron

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hello everyone,

I’m experiencing issues with an application on my NVIDIA Jetson Xavier NX Developer Kit (JetPack version 5.1.3, Codename Jakku). The application communicates over two serial ports (/dev/ttyTHS0 and /dev/ttyTHS1) and works perfectly when I run it manually via SSH as the user vc. However, when I try to launch it automatically at boot—either using systemd or a cron wrapper—the serial ports appear to open correctly, but no data is transmitted or received.

System Details:

  • Device: NVIDIA Jetson Xavier NX Developer Kit
  • JetPack Version: 5.1.3 (Codename Jakku)
  • User: vc (with proper group memberships, e.g., dialout)
  • Serial Devices: /dev/ttyTHS0 and /dev/ttyTHS1 (both active as verified via systemctl)

Application Details:

  • The application is located in my workspace (e.g., under /home/vc/my_app).
  • It requires a specific library path to be set (via LD_LIBRARY_PATH).
  • It behaves normally when run manually in an interactive session.

What I’ve Tried:

  1. Systemd Service Approach:
    I created a service unit that:
  • Waits for the network and the serial devices to be ready.
  • Sets up the environment using an EnvironmentFile and explicit PATH.
  • Adds supplementary groups for access to the serial ports.However, the service only functions properly if I manually restart it after logging in via SSH.
  1. Cron with a Wrapper Script:
    I wrote a wrapper script that:
  • Waits 20 seconds to allow for system and device initialization.
  • Sources the user’s environment.
  • Sets the required library path.
  • Launches the application while logging its output.This script is scheduled in vc’s crontab with the @reboot directive. Despite this, the application fails to work correctly at boot, but when I manually restart it after an SSH login, it works as expected.
  1. User Switch via su/sudo:
    I also attempted to run a wrapper as root that switches to the vc user using commands like su - vc -c "..." or sudo -u vc -H bash -l -c "..." to force a full login environment for vc. Unfortunately, this approach still results in the serial ports opening without proper communication until I intervene manually post-boot.

Observations:

  • At boot, the environment appears to be minimal compared to a full interactive SSH login. This might affect serial port initialization.
  • Environment dumps indicate that certain session-specific variables and supplementary group information are not fully loaded until after a proper login session.
  • Restarting the application manually after an SSH login consistently resolves the issue.

Questions:

  • Has anyone encountered a similar issue with serial communication on the Jetson Xavier NX when launching applications via systemd or cron?
  • What is the recommended method to force a full login environment (with all necessary environment variables and group memberships) for an application that relies on serial communication?
  • Could there be any Jetson-specific initialization or timing issues affecting serial devices at boot?

I appreciate any insights or suggestions to ensure that my application receives the same environment and permissions as when I log in via SSH.

Thanks in advance for your help!

3

Hi dennis.tunaev,

For a test, could you extend this delay to 3mins to confirm everything done to check if it could help?

Have you used the scope to check if there’s any data at this moment?
Or have you just verified with a loopback test?

4

Some details to summarize if you can:

  • Before you run this manually over ssh, if you run “ls -l /dev/ttyTHS0 /dev/ttyTHS1” (shows verbose ls for both files), what do you get for “group”?
  • Which user is performing the open, and is that user a member of the group, or is that user depending on the “other” permissions? Note that you can examine group memberships by grep’ing for your user name in “/etc/group”.
  • Normally root can access any serial device, but individual users have to be a member of the group.
  • Group “dialout” indicates the port is free to use.
  • Group “console” indicates the port is owned by another process.
  • If you want to add a user to the group “dialout”, then you can do so like this (I’m pretending the user name is “user”):
    sudo usermod -aG dialout user