search

raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.19k stars 1.68k forks source link

FTDI USB Serial Hangs #88

Open jromang opened 12 years ago

jromang commented 12 years ago

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 12 years ago

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 commented 12 years ago

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: https://github.com/raspberrypi/firmware/issues/88#issuecomment-8399898

Sent from my mobile device

jromang commented 12 years ago

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

ghollingworth commented 12 years ago

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: https://github.com/raspberrypi/firmware/issues/88#issuecomment-8493807

Sent from my mobile device

popcornmix commented 12 years ago

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

Jbravo2 commented 12 years ago

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 commented 12 years ago

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

markushx commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

gholling commented 12 years ago

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.

markushx commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

dehole commented 11 years ago

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 11 years ago

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 commented 11 years ago

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

popcornmix commented 11 years ago

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

tedstriker commented 8 years ago

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:

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 commented 8 years ago

Can you identify the kernel version of the working Pi?

tedstriker commented 8 years ago

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 commented 8 years ago

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

PeterPablo commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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

JamesH65 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

chrisspen commented 6 years ago

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 commented 6 years ago

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.