I'm developing firmware for an embedded device which uses an FT230X. It sends somewhat bursty raw binary data to the host at 3000000 bps. Presently I'm not sending any data from the host back to the device, though I'll start doing that shortly. I'm finding that the input side of the ftdi_sio driver seems to get stuck after some seemingly random amount of data has been read. I'm putting the device in raw mode with just about everything disabled, and verifying that with stty: $ stty -a </dev/ttyUSB0 speed 3000000 baud; rows 0; columns 0; line = 0; intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke When the input gets stuck, killing the program reading the input and starting it again resumes the data flow. This happens whether the program is cat, od, or my own program. At first I thought this was some data dependency, and that some received byte value was being treated as a special character, but I changed my firmware to just continuously send a 00 through ff sequence, and it usually manages tor read that entire sequence many times before the input gets stuck. Also, it doesn't get stuck at a consistent place in that sequence. When my firmware does send out 00 through ff at maximum rate, it usually takes longer for the input to get stuck than if I send the real application data, which is bursty. I've tried reducing the data rate to 1500000 or 1000000 bps, but the same thing happens. I'm reasonably convinced that the firmware on my embedded device isn't doing anything wrong, as its TxD line is still transmitting when the input gets stuck, and it has no feedback whatsoever indicating that the program on the host has been killed then restarted. It also seems to work fine on a Windows host for as long as I let it run. I'm running Fedora 20 64-bit with kernel 3.15.4-200. I don't expect anyone to debug this for me, but could use some advice on how I might go about debugging the problem if it is in the ftdi_sio driver. I've worked on other Linux device drivers, but not serial or USB drivers. Thanks! Eric -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
