Serial port over USB in Linux changes unexpectedly

Question

I have a problem with a custom electronic device communicating with a workstation via RS232 on USB interface. As soon the device is connected, it receive, says, the address /dev/ttyUSB0 , after some (random ) time of sending receive commands, the device appear to hang. By looking at the device events ( dmesg ), we found the following error:

ftdi_sio ttyUSB0: failed to get modem status: -32
...
USB disconnect, device number 29
[66208.321174] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[66208.497613] usb 1-1.5: new full-speed USB device number 30 using ehci-pci
[66208.589052] usb 1-1.5: New USB device found, idVendor=0403, idProduct=6001
[66208.589055] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3

So apparently the system notices a device disconnection/reconnection, thus, the device is mounted to another port, ie / dev/ttyUSB1 , causing further communication failure. Creating a test bed changes the behavior: error seems to appear less frequently, while using a complete application the error appears recurrently. Application uses jSSC-2.8.0 to communicate with the serial port. The whole application is written in java 8, and uses the Restle library to issue some REST requests to some web services. What can cause these strange behavior?

ADDED as per @DarkFalcon comment below, test bed polls the device usually faster than the real app: this could possibly explain why test perfors better than the other.

Answer 1

The problem was due to power management: the box decided the device is idle and after a certain time it removes the power. The device then apparently comes alive again in almost 0 time. So the strange behavior

Answer 2

This error is printed by driver due to broken pipe. See ftdi_get_modem_status() in driver file drivers/usb/serial/ftdi_sio.c .

You may try other libraries like 'serial communication manager', purejavacom etc. And see if problem persist. I feel, first identify who is actually creating problem; your app, serial library or driver. Then accordingly move forward. Driver has been tested and probably either library or app might have something we need to rectify.