I have a problem where port settings for serial ttyUSB ports work, but are randomly delayed for upwards of 20 seconds.
Sorry, this bears a bit of a description, I do summarize it at the bottom to clarify.
I’m working on an embedded board, using the BBB to replace an Intel ATOM architecture. We have always used multiple FT232 USB serial devices. We manufacture these devices, and therefore we set the product ID’s to be unique, but still within the FTDI range of numbers. In other words, the normal vendor ID is 0x0403 and the normal product ID is 0x6001. We also use product ID’s 0x6006 and 0x6008 to more easily discriminate our different serial slave devices.
We have absolutely no problem with detection, enumeration, device mapping, and so forth. This somewhat surprises me because I originally modified the FT232 driver on the ATOM version of Linux to recognize these other product IDs. In the case of the BBB, it recognizes and enumerates these product IDs with no fuss and no modifications to the FT232 driver.
About 50% of the time I have absolutely no problem setting the serial port rate and setting the port for raw mode. These are the equivalent of issuing the shell command: “stty -F/dev/ttyUSB0 115200 raw”; however instead of doing this, it is done within a C program and thus uses tcgetattr(), tcsetattr(), cfmakeraw(), and tcflush().
My code checks the returns from all these functions and there are never any errors in the view of the application space.
What I see the “bad” ~50% of the time is that the function calls are performed to set the port up, they give no indication that there are any problems and my application proceeds to look for received data from the port(s) and sees no interface errors at that point either, with the exception that there is no data. The problem is that a delay occurs, nominally 10-20 seconds where the port is not working properly.
In checking my system log, I see that the devices were detected and enumerated:
[ 14.943218] usb 1-1.3: Detected FT232RL
[ 14.943231] usb 1-1.3: Number of endpoints 2
[ 14.943244] usb 1-1.3: Endpoint 1 MaxPacketSize 64
[ 14.943255] usb 1-1.3: Endpoint 2 MaxPacketSize 64
[ 14.943267] usb 1-1.3: Setting MaxPacketSize 64
[ 14.977280] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
[ 14.977448] ftdi_sio 1-1.4:1.0: usb_probe_interface
[ 14.977467] ftdi_sio 1-1.4:1.0: usb_probe_interface - got id
[ 14.977493] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
[ 14.977641] usb 1-1.4: Detected FT232RL
[ 14.977654] usb 1-1.4: Number of endpoints 2
[ 14.977666] usb 1-1.4: Endpoint 1 MaxPacketSize 64
[ 14.977678] usb 1-1.4: Endpoint 2 MaxPacketSize 64
[ 14.977689] usb 1-1.4: Setting MaxPacketSize 64
[ 14.989228] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB1
I also see these devices in my usbserial file:
cat /proc/tty/driver/usbserial
usbserinfo:1.0 driver:2.0
0: module:ftdi_sio name:“FTDI USB Serial Device” vendor:0403 product:6006 num_ports:1 port:1 path:usb-musb-hdrc.1.auto-1.3
1: module:ftdi_sio name:“FTDI USB Serial Device” vendor:0403 product:6001 num_ports:1 port:1 path:usb-musb-hdrc.1.auto-1.4
And lsusb shows these devices properly as well:
lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0403:6006 Future Technology Devices International, Ltd
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
In the failed case I also see in my system log, errors such as these:
[ 33.848101] ftdi_sio ttyUSB1: ftdi_set_termios FAILED to set databits/stopbits/parity
[ 34.103915] usb 1-1: khubd timed out on ep0in len=0/4
[ 34.894929] usb 1-1.4: wandd timed out on ep0out len=0/0
[ 34.894958] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
In the cases where I see no latency (delay) in talking to my slave serial devices, I do not see those system log failure reports regarding changing the USB port settings.
In the cases where I do see a latency in talking to my slave serial devices, I do see those failure reports.
To be clear:
- From the programmer’s interface, there are no bad returns, everything seems normal in both cases.
- The sole difference is that on power up for both cases, one case has a latency and being an embedded device which shows data information as soon as available, it’s obvious that there’s a lengthy delay, the other case it works fine.
- The only indicator about this are the complaints which I see in the system log.
- The test cases are identical. Power on, system is set up to run the application at startup, some percent of time it works with no delays; some percent of time it still works, but has multi-second delays in excess of 10-20 seconds.