2
votes

I'm using an Arduino Nano, previously an UNO, to collect data from sensors and then send the data back over a USB connection through a powered hub to a Raspberry Pi model B running Jessie 4.1.19+ Mar, 15 2016 and Python 2.7. The python code uses pyserial readline to get the data.

In general it works fine but occasionally (typically a couple of times a day) it fails with the above message. It seemed the only way to fix it was to unplug the USB connection, reconnect it and restart the program. I altered the code to catch the exception but it wouldn't reopen the connection, giving the error:

serial.serialutil.SerialException: could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'

This problem occurs with both the UNO (on /dev/ttyAMA0) and the NANO (on /dev/ttyUSB0).

Just recently I discovered that following this fault the Nano had moved to /dev/ttyUSB1. The python code will then run successfully against /dev/ttyUSB1 but when the problem occurs again it switches back to /dev/ttyUSB0.

As a result, I have changed the code to intercept the exception and open the alternative device and carry on. So far this is working fine but its clearly not right.

Can anyone suggest where the problem might lie and how I could go about diagnosing it? I'm not super-technical! Also, I've seen a couple of other posts on this subject but reverting back to a previous kernel level is not really practical in this instance.

Updated to include log output below. There are two devices: NANO (1a86:7523) and an OWL power monitor (0fde:ca05).

$ dmesg -T
[Sat Feb 11 14:53:02 2017] usb 1-1.3-port2: disabled by hub (EMI?), re-enabling...
[Sat Feb 11 14:53:02 2017] usb 1-1.3.2: USB disconnect, device number 71
[Sat Feb 11 14:53:03 2017] dwc_otg_hcd_handle_hc_fsm: 173 callbacks suppressed
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1649 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1650 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1651 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1652 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1653 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1654 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1655 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1656 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1657 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] Transfer to device 72 endpoint 0x1 frame 1658 failed - FIQ reported NYET. Data may have been lost.
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: new full-speed USB device number 73 using dwc_otg
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: New USB device found, idVendor=0fde, idProduct=ca05
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: Product: OWL Wireless Electricity Monitor USB version is connected
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: Manufacturer: Silicon Labs
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: SerialNumber: 001A3C26
[Sat Feb 11 14:53:03 2017] cp210x 1-1.3.2:1.0: cp210x converter detected
[Sat Feb 11 14:53:03 2017] usb 1-1.3.2: cp210x converter now attached to ttyUSB0
[Sat Feb 11 14:53:03 2017] usb 1-1.3-port3: disabled by hub (EMI?), re-enabling...
[Sat Feb 11 14:53:03 2017] usb 1-1.3.3: USB disconnect, device number 72
[Sat Feb 11 14:53:03 2017] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
[Sat Feb 11 14:53:03 2017] ch341 1-1.3.3:1.0: device disconnected
[Sat Feb 11 14:53:03 2017] usb 1-1.3.3: new full-speed USB device number 74 using dwc_otg
[Sat Feb 11 14:53:03 2017] usb 1-1.3.3: New USB device found, idVendor=1a86, idProduct=7523
[Sat Feb 11 14:53:03 2017] usb 1-1.3.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[Sat Feb 11 14:53:03 2017] usb 1-1.3.3: Product: USB2.0-Serial
[Sat Feb 11 14:53:03 2017] ch341 1-1.3.3:1.0: ch341-uart converter detected
[Sat Feb 11 14:53:03 2017] usb 1-1.3.3: ch341-uart converter now attached to ttyUSB2
[Sat Feb 11 14:53:05 2017] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[Sat Feb 11 14:53:05 2017] cp210x 1-1.3.2:1.0: device disconnected

1

1 Answers

0
votes

I know this is an old thread but I hit this issue recently with my Raspberry Pi 3 Model B Rev 1.2 running a stock Debian kernel 5.4.0-3-arm64 while connecting a 3018 CNC Pro controller board. When I lsusb, the board appears as

Bus 001 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Whenever I would open the serial port, the usb device would reset. I searched far and wide, applied a bunch of config parameters from different forums but the issue turned out to be power-related for me.

While the 3018 CNC Pro board has an independent power supply, the usb-serial chip on the board is bus-powered (noticed this in lsusb -v). My Raspberry Pi has plenty of available power but I was running the 1m usb cable through a metal clip and along a metal channel which must have had enough inductance to resist the required surge of power through the usb cable. Removing the clip solved the problem.

Hopefully this note helps someone!