Hello everyone,
I am using a BeagleBone Black to interface between a weather station and radio modem. I am using two USB to serial converters and am experiencing USB system crashes which I have not yet been able to solve. I am thinking there may be some type of a conflict with the drivers when using both adapters. Details below…
–Hardware–
I am using an FTDI CHIPI-X10 USB to RS232 Serial converter to connect with the radio modem and an FTDI USB-RS232-WE-1800-BT_0.0 Wire Ended USB to RS232 Serial converter to connect to the weather station. Both converters plug into a Tripp Lite U225-004-R 4-port USB hub, which is then connected to the BeagleBone Black USB connection.
Both the weather station and radio/modem are externally powered so the only USB power consumption is that of each of the converters and the 4-port hub. The hub was originally powered directly from the BeagleBone Black but I am now powering it externally.
I believe the BBB is a Revision B board but I will have to double check that. The board is powered from a 12 volt step down converter which I adjusted to 5 volt output. With the system powered I measure 4.98 volt to 5.00 volt with a multi-meter. I have not measured the current flow to the BBB, but I designed the power supply system, including the step down converter, to handle the anticipated load.
–Software–
I am running Debian 8 (Jessie) on the internal eMMC storage. The image was the newest when I downloaded it around May. The OS is up to date as of Monday using apt-get upgrade. The kernel has also been upgraded from 4.4.54-ti-r53 to 4.9.44-ti-r55 in the hopes of correcting the issue. I have disabled the software that directly talks to the radio modem, and am using a combination of a python script I wrote and minicom to read data from the weather station.
–Issue and Troubleshooting–
With both converters connected, when reading the 1Hz rate data sent from the weather station, the USB system will crash within 2 seconds to 2.5 hours with a ftdi_sio error shown in dmesg. The error most often is: “ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32”. After upgrading the kernel the error was different, similar to “failed to get modem status: -71”. As I have switched around the order in which the converters are plugged into the hub the ttyUSBx port the crash occurs on changes, but I believe it is always the one connected to the weather station as that is the one always being accessed for testing.
In my online research I have found many mention of the “usb_serial_generic_read_bulk_callback” fault in Raspberry Pi related discussions and the most often suggested and working fix is to add the parameter “dwc_otg.speed=1” to /boot/cmdline.txt which forces USB to revert back to USB1.1. Although I have no need for USB2.0 speeds, it appears this is not able to be done with the BBB, in addition to /boot/cmdline.txt not existing.
There are also many instances of current draw being too great and causing the issue. Though doubtful because of a <~200mA calculated current draw, I switched to externally powering the USB hub. After doing this I am no longer seeing the “-71” fault and only seeing the original “ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32” one.
When I was first building and testing the system on my bench I had what turns out to be the same issue, although I did not pursue it then. At the time I was using a Prolific chip based USB to Serial adapter for the radio modem which I suspected was the culprit. Once I replaced it with the CHIPI-X10 I had no further trouble until installing the entire system this weekend.
In my troubleshooting I have completely disconnected the CHIPI-X10, which is connected to the radio modem, and accessed the converter connected to the weather station. In this test I was able to read the data for nearly 24 hours without issue until I stopped it for more troubleshooting. I have not conducted a similar test with the adapters reversed, although I saw no signs of any issue during my earlier bench testing.
I have provided the system information below. The dmesg output was gathered after the crash occurred and I filtered it to show only USB related lines.