FTDI USB Serial Hangs

[jromang]

Problem detail : http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=8010

I, like a few others, have been having various problems using USB/Serial adapters with RPi. One of them is the FTDI adapter and so far my search for an answer has been unsuccessful.

The problem is the device is recognised by RPi and lists correctly from dmesg

usb 1-1.2.3: new full speed USB device number 5 using dwc_otg
usb 1-1.2.3: New USB device found, idVendor=0403, idProduct=6001
usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.3: Product: USB <-> Serial
usb 1-1.2.3: Manufacturer: FTDI
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for FTDI USB Serial Device
ftdi_sio 1-1.2.3:1.0: FTDI USB Serial Device converter detected
usb 1-1.2.3: Detected FT232BM
usb 1-1.2.3: Number of endpoints 2
usb 1-1.2.3: Endpoint 1 MaxPacketSize 64
usb 1-1.2.3: Endpoint 2 MaxPacketSize 64
usb 1-1.2.3: Setting MaxPacketSize 64
usb 1-1.2.3: FTDI USB Serial Device converter now attached to ttyUSB0
usbcore: registered new interface driver ftdi_sio
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

But as soon as you try to access the device it hangs the RPi requiring a reset.

I do not know what the problem is, the FTDI driver has been part of the kernel for some time, the avenue I am pursuing now is that the driver is not ARM compatible, the FTDI web site doesn't list an ARM linux driver (cant say if that's even relevant).

There is this http://www.ftdichip.com/Support/Documen ... ndroid.pdf regarding cross compiling to ARM (for Android).

So my train of thought is that the current driver is not ARM compatible and requires compiling for ARM, with all that entails and the pitfalls associated.

However I may be barking up completely the wrong tree so any more experienced kernel/driver peeps with a thought?

[Ferroin]

I can confirm that at least some FTDI chips work, because I have successfully used the one built into an Arduino Nano for a serial connection, although I don't know if this is a different chip or just a different circuit that it is connected to. I have had latency problems with it however if I try to use it at above 9600 baud.

[ghollingworth]

Yes,

The large interrupt requirement slows down the processor
significantly, but it can work (I guess it depends upon which chip it
is)

Work is progressing

Gordon

On 09/09/2012, Austin S. Hemmelgarn notifications@github.com wrote:

I can confirm that at least some FTDI chips work, because I have
successfully used the one built into an Arduino Nano for a serial
connection, although I don't know if this is a different chip or just a
different circuit that it is connected to. I have had latency problems with
it however if I try to use it at above 9600 baud.

---

Reply to this email directly or view it on GitHub:
#88 (comment)

Sent from my mobile device

[jromang]

I try to use it at 9600 baud, and it hangs immediately.
Do you need some information or log file ?

[ghollingworth]

No,

I've got one here and am working on it...

Gordon

On 12/09/2012, Jean-Francois Romang notifications@github.com wrote:

I try to use it at 9600 baud, and it hangs immediately.
Do you need some information or log file ?

---

Reply to this email directly or view it on GitHub:
#88 (comment)

Sent from my mobile device

[popcornmix]

The NAK holdoff fix added to kernel a few days ago may fix this. Please update and test.

[Jbravo2]

I'm running Linux raspberrypi 3.2.27+ #171 PREEMPT

I got a FT232BM (embedded in a card reader), the device is discovered correctly, but when accessing /dev/ttyUSB0 the RPi just hangs.

When forcing usb to full speed in cmdline.txt as described here; http://www.raspberrypi.org/phpBB3/viewtopic.php?p=164633#p164633

the device works as expected, but performance of usb full speed in not acceptable.

[Jbravo2]

HW related?
http://www.ftdichip.com/Support/Knowledgebase/index.html?whydoesntmyft232245workwhenco.htm

[markushx]

We have a tried all mentioned boot command line and sysctl changes from here and the forums with an FT232BM. No luck for us so far. Has someone tried the capacitors mentioned in the FTDI knowledgebase with success? Is FTDI aware of the problems with RPi?

[gholling]

Jbravo2 found that forcing usb to full speed fixed the problem for him, (this suggests it is an interrupt overhead issue) can you make sure that this is working properly? You should see a severe reduction in the ethernet throughput if you've set the cmdline parameter correctly.

Gordon

[markushx]

With dwc_otg.speed=1 the RPi hangs on boot for me. (Newest firmware and dist-upgrade.)

[gholling]

Even if its not plugged in?

Gordon

From: Markus Becker [mailto:notifications@github.com]
Sent: Wednesday, October 31, 2012 03:34 AM
To: raspberrypi/firmware firmware@noreply.github.com
Cc: Gordon Hollingworth
Subject: Re: [firmware] FTDI USB Serial Hangs (#88)

With dwc_otg.speed=1 the RPi hangs on boot for me. (Newest firmware and dist-upgrade.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-9939855.

[markushx]

Even then. It waits quite some time on "configuring network" and does not take input from the USB keyboard when the login finally shows up. Without dwc_otg.speed=1 it boots fine, but hangs on using the FT232BM.

Markus

[winstonma]

I used the ftdi_sio driver before. Now I followed the step on the official web site and use the d2xx driver.

I downloaded the d2xx package (Link) and followed the steps on the readme file (Link). However the library doesn't work. After finding the correct library online I tried to run the C program in the d2xx package.

I ran the read program (release/examples/EEPROM/read/read). It provided me the information below:
Library version = 0x10112
Opening port 0
FT_Open succeeded. Handle is 0xcd240
FT_GetDeviceInfo succeeded. Device is type 5.
FT_EE_Read succeeded.

Signature1 = 0
Signature2 = -1
Version = 2
VendorId = 0x0403
ProductId = 0x6001
Manufacturer = FTDI
ManufacturerId = AM
Description = FT232R USB UART
SerialNumber = AM01FBFO
MaxPower = 90
PnP = 0
SelfPowered = 0
RemoteWakeup = 1

232R:

    UseExtOsc = 0x0
    HighDriveIOs = 0x0
    EndpointSize = 0x40
    PullDownEnableR = 0x0
    SerNumEnableR = 0x1
    InvertTXD = 0x0
    InvertRXD = 0x0
    InvertRTS = 0x0
    InvertCTS = 0x0
    InvertDTR = 0x0
    InvertDSR = 0x0
    InvertDCD = 0x0
    InvertRI = 0x0
    Cbus0 = 0x3
    Cbus1 = 0x2
    Cbus2 = 0x0
    Cbus3 = 0x1
    Cbus4 = 0x5
    RIsD2XX = 0x0

Returning 0

Then I looped the program in a bash script (while true; do ./read; sleep 2; done). After 5 minutes the system crashed with the same DMA error ("handle_hc_chhltd_intr_dma").

The DMA error is described here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=16280

[markushx]

I have also checked against kernel 3.6.1+ and it hangs there as well.

[dehole]

I just discovered this issue while trying to get the Raspberry Pi to program an ATMEGA328 via a USB serial cable. Is it working on the 512MB Raspberry Pi's?

[dehole]

Looks like my issue is fixed in the latest raspberry pi firmware (3.6.11+ #414 PREEMPT). Thanks guys, now I can program it without it freezing.

[popcornmix]

Can anyone else still suffering from this issue try latest (rpi-update) firmware?
It may have helped this issue.

[popcornmix]

No reports of it still failing, so closing. Reopen if the problem still exists with latest kernel.

[tedstriker]

It seems like the hangs are back. There's no lockup of the Pi, but the serial interface stops responding after some time.
Having a RPI3 with latest firmware-update 4.4.8-v7+ #881 SMP Sat Apr 30 12:16:50 BST 2016 armv7l GNU/Linux

To remove most of error sources I made this simple test setup differentt arduinos <-> different USB to serial FTDI Adapters <-> minicom on RPI3 as terminal
Value "1" is sent an button push and "0", when released.

It has been tried with different serial adapters, different arduinos and different raspis.

The results are:

• the value of 1 or 0 are being displayed delayed with varying delay time.
• a few quick button pushes (4-5) seem to be buffered and displayed in a whole when the delay is over
• it looks like the buffer is polled every few moments up to 1 or 2 seconds.
• if the button is pushed consecutively for a longer time (>4 sek) the responsiveness increases and the button pushes are displayed immediately
• after a few hours no data arrives in the terminal anymore.

Also I tried it with another RPI1 B. It responds immediately and doesn't seem to have that issues, but it has an out-dated firmware running.
On a RPI1 B+ with the more recent firmware 4.1.21+ #872 Wed Apr 6 17:27:13 BST 2016 armv6l GNU/Linux it's got the same problems like on the RPI3

[popcornmix]

Can you identify the kernel version of the working Pi?

[tedstriker]

I think it was "4.1.12 Oct 28 2016", but I can check back on monday, when I'm back at work.
Today I tried another RPI 1B+ with firmware 4.1.19+ #858 Tue Mar 15 15:52:03 GMT 2016 armv6l GNU/Linux with the same delay issue.
Adding dwc_otg.speed=1 to the cmdline.txt didn't help, too.
Also I swapped the power source to rule out power problems. The delays were the same.

If I can provide other information that helps narrowing it down, let me know.

[popcornmix]

Find the exact kernel version that worked to begin with.
We may need to narrow it down further later.

[PeterPablo]

I could help with testing, as I started using FTDI USB-to-serial adapters on a Raspberry Pi 2B recently. Usually I am running it with either 9600 Baud (8-N-1) or 57600 Baud. I am not using any handshaking. Readout is done using the nice python library PySerial. With my limited experience I did not encounter any issues yet.
My config.txt is unchanged apart from max_usb_current=1, which is needed so I can attach an external 2,5" HDD.

[tedstriker]

Good to here that it might not be a problem in general.
Anyways, the version that appears to be working is 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux
My serial device is running at 115200 Baud 8N1.

[popcornmix]

So the issue occurred between 4.1.13 and 4.1.19?

Can you identify the exact update which caused this. See:
https://github.com/Hexxeh/rpi-firmware/commits/master

If you click on each commit the end of the url contains a git hash. Run
sudo rpi-update <hash>
to revert back to that version. Report the first version with the error.

[tedstriker]

Weird thing. I downgraded the RPI 1 B+ to 4.1.13 and the lags were still showing.
On RPI 1 B with 4.1.13 are no lags.
Seems like it's not the firmware then...

Side-note:
Also reduced the baud-rate from 115200 to 57600 with no different outcome.

[jwatte]

This still happens. Rpi 3, latet jessie as of today.
Serial device is a Teensy 3.2.
USB serial wedges almost immediately after communications start up.

[chrisspen]

I think I'm seeing this. I'm trying to communicate between a RPi3 and an Arduino Uno using Pyserial. My baud is 57600, and if I only transmit a couple bytes a minute, it works fine, but when I try to send a few KB, it hangs after a couple minutes. My Arduino toggles an LED every second, which keeps toggling even after the Pi reports a serial hang, so I know it's not the Arduino crashing or getting hung up with buffer overflows. However, Pyserial's reporting that all writes and reads timeout. If I programmatically reset the serial connection by toggling DTR, that temporarily fixes it, but the hang soon happens again.

[chrisspen]

Since this problem is still occurring, can someone please re-open this?

[JamesH65]

It's quite possible this is a problem with Pyserial. Is it possible to test this using another library, or perhaps directly with Linux and/or C code? Also, which kernel version are you using?

[jwatte]

I'm getting this with basic open()/tcgetattr()/cfmakeraw()/tcsetattr() control.
That being said, I think the problem might be in upstream Linux USB serial drivers, because I've seen this problem on other Linux systems, too.
Also, cfmakeraw() doesn't turn off IXOFF, only IXON, IIRC, so updating the flags to do that might help?

[chrisspen]

@JamesH65 My kernel is: 4.9.31-v7+ #1005 SMP Thu Jun 8 13:02:15 BST 2017 armv7l armv7l armv7l GNU/Linux

[chrisspen]

An odd thing I've noticed is that after a fresh reboot, my Pi and Arduino can communicate just fine. I let it run for 12 hours, and the serial port didn't hang at all. Then I stopped by Pyserial script, disconnected the Arduino, connected it to my development laptop, re-uploaded the identical code (no firmware was changed), then reconnected it to my Pi and re-ran the Pyserial code...and it started having connection problems almost immediately. It still worked for a couple minutes, but my Pyserial script reported a lot more intermittent timeouts and corrupted checksums until finally the port completely froze.

I then rebooted my Pi, and although the code was unchanged, it again worked. My pyserial code runs fine for hours...until I disconnect and then reconnect the Arduino.

I stumbled across this behavior while testing various tweaks to /boot/cmdline.txt. I noticed that every time I tested a new configuration, it always seemed to work fine, but when I disconnected and reconnected the Arduino, it then suddenly started to fail, even if I didn't change any firmware on the Arduino.

Is there some OS daemon (udev maybe?) running on the Pi that needs to be restarted after a USB device is removed?

[chrisspen]

The hang-after-reconnect problem seems to go away when I add dwc_otg.speed=1 to my /boot/cmdline.txt, implying this is again the often-reported bug in the high-speed USB driver. My full cmdline.txt, that I dare say might be working, is:

net.ifnames=0 biosdevname=0 dwc_otg.lpm_enable=0 dwc_otg.fiq_fix_enable=1 dwc_otg.microframe_schedule=1 dwc_otg.nak_holdoff_enable=1 dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3 dwc_otg.speed=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait quiet splash

I tried virtually every other option before I tried dwc_otg.speed, so the others might not be necessary. However, it'll take me a while to test their removal one by one.