RPI 1 B+ FT232 disconnecting

[andreisocol]

Hello,

Using minicom (sudo minicom -b 19200 -o -D /dev/ttyUSB0) to read values transmitted through USB by an Arduino connected to a FTDI 232 stops at random intervals.
Tried multiple FT232 devices, all having same behavior.
Also tried short USB cables. Same behaviour.

uname -a
Linux raspberrypi 4.1.12+ #824 PREEMPT Wed Oct 28 16:39:49 GMT 2015 armv6l GNU/Linux

lsusb
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

cat /var/log/kern.log
......
Nov 4 11:07:24 localhost kernel: [ 7.061210] usbcore: registered new interface driver ftdi_sio
Nov 4 11:07:24 localhost kernel: [ 7.169491] usbserial: USB Serial support registered for FTDI USB Serial Device
Nov 4 11:07:24 localhost kernel: [ 7.244932] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Nov 4 11:07:24 localhost kernel: [ 7.321776] usb 1-1.4: Detected FT232RL
Nov 4 11:07:24 localhost kernel: [ 7.387123] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
.......
Nov 4 14:22:49 localhost kernel: [11736.542211] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Nov 4 14:23:13 localhost kernel: [11761.350820] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

[popcornmix]

@P33M any suggestions?

[andreisocol]

PS : I have always connected the FTDI directly to the RPI's USB ports.
Here is the full output of lsusb and lsusb -v.

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 005: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 FT232R USB UART
iSerial 3 A50285BI
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 FT232R USB UART
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

[andreisocol]

I have closed this by mistake, reopening.

[P33M]

Are you running with max_usb_current=1 in config.txt?

[andreisocol]

/boot $ cat config.txt | grep -i usb - returns nothing.

Also, only uncommented line in /boot/config.txt is :
gpu_mem=128

[P33M]

I'd try with the max current setting enabled. Spurious disconnects could be a symptom of bumping up against the current limit.

[andreisocol]

The Arduino with attached sensors consumes only 27mA + the FT232 which I see it can consume max 90mA. Besides the Arduino + FT232, only an Edimax wifi was connected.
No external USB HUB, no keyboard, no mouse. So consumtion was minimum.
But I could try the max current setting.
Please tell me the value I have to set for the variable "max_usb_current" from /boot/config.txt
Thank you,

[P33M]

max_usb_current=1 enables the higher limit (1.2A).

[andreisocol]

After modifying and rebooting, I have tested and after 3 minutes of data transfer, it disconnected again.

Nov 5 13:16:58 localhost kernel: [ 315.181705] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Nov 5 13:17:16 localhost kernel: [ 333.071267] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

[P33M]

Can you try instead with dwc_otg.fiq_fsm_mask=0x0 set in /boot/cmdline.txt?

[andreisocol]

@P33M
This is the line I got right now :

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Where should I add dwc_otg.fiq_fsm_mask=0x0 ? Does it matter ? Or do I just have to add at the end of the current line ?

[P33M]

Add the parameter anywhere in the line, with a space before and after.

[andreisocol]

Added the configuration, rebooted but minicom it is still disconnecting at random intervals (not bigger then 5 minutes).
@P33M Any other suggestions ?

[P33M]

You could try the nuclear option - add dwc_otg.speed=1 to /boot/cmdline.txt - this forces the entire bus to USB1.1 speeds. If you still get disconnects after that, then it's probably safe to say that the Pi isn't the issue.

[andreisocol]

After adding the option dwc_otg.speed=1 and rebooting, the FTDI transmission does no longer stop working. Since 30 minutes it's working perfectly.
I will try increasing the baud rate from 19200 in incremental steps, till 115200 and see what will happend.
Will post the results by tomorrow.
Thank you all for your support.

[andreisocol]

Increased the baud rate at 115200 (sudo minicom -b 115200 -o -D /dev/ttyUSB0)
It's been runing at that speed for 160 minutes without any issues.
Will reboot the device, do a kernel update and further test the stability of the configuration.
Will post the results, but things are looking good right now.

[andreisocol]

I had no new kernel updates to apply. Rebooted the device, and now I've got another 160 minutes of communications without any issues.
I will try and revert back to usb 2.0 speed and see if the problem reoccurs.
Will update on the status.

[andreisocol]

18 + hours without any disconnects.
I can confirm that by using dwc_otg.speed=1 solved the problem, but reduced the usb speed to usb 1.1.

[andreisocol]

27 hours without any problems.

[andreisocol]

Reverted the configuration back to usb 2.0, rebooted, and after less then 1 minute the ftdi data transfer stopped.
Can we dig deeper to try and understand why this is hapening or is this a known issue without solution ? If no, I will close this topic as solved.
Thank you all for helping me.

[kenji21]

Same issue with a Pi 2. I'm using a ftdi with some -32 errors "broken pipe" :
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

With the dwc_otg.speed=1 the problem has disappeared (I will let it because I don't need usb speed).

EDIT :

uname -a
Linux osmc 4.1.3-2-osmc #1 SMP PREEMPT Tue Aug 4 11:44:21 UTC 2015 armv7l GNU/Linux

[andreisocol]

Hello everybody,
After setting "dwc_otg.speed=1" in /boot/cmdline.txt (this forces the entire bus to USB1.1 speeds), I have tested and no issues occured. More than 70+ hours of non-stop communication without any errors.
As I have found no other ways to solve this, and I am happy with the solution (no problems with other USB connected equipment like keyboard, mouse, USB HUB, wifi, memory stick, etc.), I will close this topic.
Hope other people will use their FTDI without issues on the raspberry.
Thank you all,

[Kr4ntz]

Thanks for the info -- I´ve been having the same issues with a PI + Arduino.... now I know what to do.

[nach1man]

Hi, I've been having issues with SIIG's FTDI usb to serial adapter... I went ahead and tried this patch, but I get adverse effects (i.e. nothing I plug into the usb port gets power). Does this patch apply to the RPi2? I'm currently running kernel 4.1.13-v7+ Raspbian Wheezy.

Thanks.

[paulctan]

I can confirm that the problem with serial port disconnects that express the syslog line:
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
is caused by FAKE FTDI chips. I tried several different FTDI usb serial boards, and it turned out that they were all fake. I purchased genuine FTDI serial board (UB232R) from Digikey, and the problem has gone away. I can verify that the batches that I had originally tried were fake because several of them had SerialNumber of 00000, and several others had serial number of A50285BI, which was confirmed to be common with fake chips - see https://softsolder.com/2016/09/02/counterfeit-ftdi-usb-serial-adapter-roundup/

I did not have to drop the USB down to 1.1, it worked correctly as soon as I put in the genuine chips.

[VigibotDev]

The dwc_otg.speed=1 do not workaround for me. This issue is not closed : the same device work perfectly on Linux Debian Jessie (and windows) and not on PI3 + Raspbian Stretch, there is a lot of device with integrated fake FTDI (radio modem...) please workaround.

[VigibotDev]

https://forums.linuxmint.com/viewtopic.php?f=49&t=226100
Does anyone know how to substitute the open-source libFTDI kernel drivers for the FTDI drivers?

[chrisspen]

It's not limited to "fake FTDI" chips. I have a genuine Arduino Uno talking with a Raspberry Pi 3, and the problem happens for me. Setting dwc_otg.speed=1 mitigated the problem, but did not completely solve it. It seems to hang less frequently now, but it's proportional to the amount of data I send. If I just have a simple program running on the Arduino sending a ping message once a second, it runs for well over a week before hanging, but if I try to transmit dozens of messages a second, it happens every few minutes. Oddly, the hang seems to auto-resolve itself now after a few minutes, whereas before it was permanent until I reset the Arduino. However, this is still immensely frustrating, and makes it virtually impossible to use an Arduino with a Raspberry Pi.

[mrx23dot]

After 3years any other solutions than turning USB to 1.1? Did anyone do a root cause analysis?

[JamesH65]

Considerable work has been done on the USB system to get round various HW limitations. If there are still problems, then you are probably hitting a HW limitation.

[mrx23dot]

I'm using RPI 3 HW, and up to date kernel, but still getting urb stopped: -32

[JamesH65]

USB HW in the SoC is the same on Pi1->Pi3. If the problem has not been fixed in the last three years, then I suspect its hitting a HW limitation. @P33M?

[P33M]

As the problem goes away with the bus at full-speed, there's likely to be a bugfix that can be done. Without representative hardware that exhibits the issue, it's going to be hard to diagnose.

[synatree]

We are chasing after this problem as well, with the following board:
https://www.sparkfun.com/products/9822

Maybe this is a clue - we are also using a PiPlate, an in certain situations setting a ADC "high" will trigger this issue on an unrelated USB-attached FTDI board. We think this may be related to increased power draw or possibly a faulty PiPlate board, but I thought I'd mention in here because in our setup it reliably reproduces this error.

[abetusk]

@synatree, could you provide your setup that reliably reproduces these errors? This probably would go a long way to fixing the issue people are able to setup something that consistently causes the bug to appear.

[SpazCode153]

Hi, I had the same problem as what andreisocol was experiencing but this did not just happen with my FTDI chip it also happened with a CH341-UART converter. By setting dwc_otg.speed=1 the problem was resolved.

[SpazCode153]

I can also confirm that the same problem happens on the RPI3 B

[MattByczko]

Also happens on brand new Raspberry Pi 4b running Fluiddpi + klipper for 3D printing.
Klipper3d/klipper#4679

[riekusr]

also have this on a Pi4 2gb

[coinstore]

Issue is gone for me since I have reinstalled my PI4b with the 32 rasbian lite instead of 64 bit.

[ForrestFire0]

I am facing this issue. Frustrating issue, crazy that it has persisted for 8 years. Seems to be the same as this: #2406