RS232 port works on boot, becomes unresponsive if unused

I am having an issue with the RS232 port. It works on first boot, but if I leave a terminal open and do not input any commands for too long it will sometimes become unresponsive. The Jetson is still running properly, I can access it via SSH over Ethernet and via HDMI/keyboard/mouse. And it seems that the getty process is still running on /dev/ttyS0.

I suspected my USB-serial cable so I swapped it out for two different kinds (Prolific and FTDI). It seemed to resolve the problem at first, but the symptom has returned after a day or two. A reboot will produce terminal text but I will be unable to issue keystrokes. A hard power off followed by a short wait is the only thing that resolves the problem.

I’m just curious if anyone else has experienced this problem, if it is reproducible, etc. And of course any suggestions/fixes welcome :)

Thanks,
Neel

Just to get the obvious out of the way, I am using 115200 8N1 no flow ctrl etc. I’ve gotten that to work.

Some USB ports are set up with automatic sleep or low power mode if not used. Jetson itself has been known to have this get in the way, but it is normal operation. It’s possible in this case that your host at the other end is what has USB sleep/low power. Unfortunately, not all USB devices wake up properly when told to do so. The sticky topic on Jetson links has some information on USB sleep and performance modes…I’m not sure how well this would apply to an x86 workstation, but it might help in figuring out if this is what is going on.

FYI, if this is a laptop host, then very likely it does have some sort of low power idle setting.

One thing I forgot to mention about serial UART is that if there is more than one and something changes, e.g., device disconnect and reconnect, the device special file will likely change. For example, I use several simultaneously, and usually my active project is /dev/ttyUSB3. If something causes one of the others to be removed, it has been known to rename the ttyUSB3 to ttyUSB2, and things mysteriously stop working. Before and after a failure, you may want to look at which serial UARTS exist and verify there was no change (“ls /dev/ttyUSB*”).

Thanks @linuxdev! I think changing the USB/serial cable dealt with the autosuspend issue… one of them was not playing nice with the host PC autosuspend. The renewed issues (what led me to post this problem) ended up being an intermittent connectivity issue inside our device that interfaces with the Jetson.

I have observed what you posted regarding device handle changing; it was not the issue in my case either time, but has definitely been an issue in other cases (especially when a USB peripheral enumerates with mutliple /dev/ttyUSBx handles!)