Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

FTDI USB Serial Hangs #88

Closed
jromang opened this Issue Sep 3, 2012 · 27 comments

Comments

Projects
None yet

jromang commented Sep 3, 2012

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 commented Sep 9, 2012

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.

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

@ghost ghost assigned ghollingworth Sep 9, 2012

jromang commented Sep 12, 2012

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

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

Contributor

popcornmix commented Sep 15, 2012

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

Jbravo2 commented Sep 25, 2012

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.

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?

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

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

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/raspberrypi/firmware/issues/88#issuecomment-9939855.

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

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

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

dehole commented Apr 23, 2013

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 commented Apr 23, 2013

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.

Contributor

popcornmix commented Apr 23, 2013

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

Contributor

popcornmix commented Jul 20, 2013

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

@popcornmix popcornmix closed this Jul 20, 2013

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

Contributor

popcornmix commented May 4, 2016

Can you identify the kernel version of the working Pi?

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.

Contributor

popcornmix commented May 5, 2016

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

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.

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.

Contributor

popcornmix commented May 9, 2016

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.

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 commented Sep 5, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment