raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RPI 1 B+ FT232 disconnecting

andreisocol opened this issue · comments


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

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

@P33M any suggestions?

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)

I have closed this by mistake, reopening.


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

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

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


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

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,


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

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


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

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 ?


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

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


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.

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.

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.

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.

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.

27 hours without any problems.

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.

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).


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

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,

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

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.


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.

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.

Does anyone know how to substitute the open-source libFTDI kernel drivers for the FTDI drivers?

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.

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

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.

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

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?


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.

We are chasing after this problem as well, with the following board:

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.


@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.

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.

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

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