* Another ISP1761 / FTDI / serial problem
@ 2011-02-08 16:26 Arvid Brodin
2011-02-08 16:30 ` Arvid Brodin
0 siblings, 1 reply; 2+ messages in thread
From: Arvid Brodin @ 2011-02-08 16:26 UTC (permalink / raw)
To: kernelnewbies
Hi!
I get weird problems when I use a null modem cable between the two ports
on a FT232BM (2-port FTDI USB-to-serial converter) with an isp1761 host
controller. The same thing does not happen with an EHCI host controller.
Lengthy details follows:
With the EHCI host controller:
=============================
[Terminal 1]
$ cat /dev/ttyUSB1
[Terminal 2]
$ echo "Something seems wrong here" > /dev/ttyUSB0
$ echo "Something seems wrong here" > /dev/ttyUSB0
[Terminal 1]
Something seems wrong here
Something seems wrong here
^C
$
Observe the extra new line after the strings. I'm not sure if this is a
bug in the ftdi driver, some other part of the serial subsystem, or if
it is the result of some terminal setting; with a USB analyzer I observe
the following sequence of packets (#-# == device-endpoint):
3-2 OUT: "Something seems wrong here"
3-2 OUT: 0x0D 0x0A
4-1 IN: 0x01 0x60 'S'
4-1 IN: 0x01 0x60 'o'
...
4-1 IN: 0x01 0x60 0x0D
4-1 IN: 0x01 0x60 0x0A
4-2 OUT: 'S' # The echo from the reading side starts here
4-2 OUT: 'o'
...
4-2 OUT: 0x0D 0x0A
4-2 OUT: 0x0D 0x0A # The newline pair is echoed twice - perhaps both
'CR' and 'NL' are converted to "CRNL" in the echo?
Anyway, since 3-1 is never read, no feedback loop is created by the two
echoing devices.
With the isp1761 host controller, driver from 2.6.35.7 backported to
2.6.27.54 and modified for platform endianness:
=============================
[Terminal 1]
$ cat /dev/ttyUSB1
[Terminal 2]
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
[Terminal 1]
This is isp1761 and something is wrong
This is isp1761 and something is wrong
This is isp1761 and something is wrong
This is isp1761 and something is wrong
This is isp1761 and something is wrong
and something is wrong
(blank line x7)
This is isp1761 and something is wrong
^C
# echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
# cat /dev/ttyUSB1
is wrong
(blank line x30 ca)
TThis is isp1761 and something is wrong
^C
#
The exact look of the error differs, but it is quite easy to trigger by
echoing text several times in a row; also breaking the "cat" execution,
echoing some more text, and then starting cat again seems to trigger the
error often.
On the bus the traffic looks something like this:
7-2 OUT: "This is isp1761 and something is wrong"
7-2 OUT: 0x0D
7-2 OUT: 0x0A (NAK) # The CRNL pair is split here and the NL is not
directly accepted by the device
7-2 OUT: 0x0A (NAK)
Following this is lots and lots of "0x0A NAKs" intermixed with traffic
that looks quite like the EHCI case except that much of the traffic has
to be re-sent lots of times before it is accepted. The 0x0A is finally
accepted after all text has been received by 8-1 and echoed from 8-2.
This exact pattern is repeated every time text is written to the serial
port.
Device 8 receives the characters and echoes them back to 7-1 as in the
EHCI case. But with isp1761, after a while device 7 for some reason
starts echoing parts of the received echo-text back. My guess is that
this should not happen since device 7 is never read from. Anyway, this
creates a feedback loop which would be the source of the spurious
characters in the "cat" run above and that sometimes is powerful enough
to make the terminal unresponsible.
I've been trying to figure this thing out for a while now but quite
frankly I'm stumped; I can't figure out where and why things goes wrong.
Any ideas are welcome! Perhaps the NAK problem/bug triggers a
problem/bug somewhere in linux' serial terminal code?
The terminal settings are the defaults and are the same during all
examples above on both serial ports:
$ stty -a -F /dev/ttyUSB0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; 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
$ stty -g -F /dev/ttyUSB0
500:5:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
--
Arvid Brodin
Enea Services Stockholm AB
^ permalink raw reply [flat|nested] 2+ messages in thread
* Another ISP1761 / FTDI / serial problem
2011-02-08 16:26 Another ISP1761 / FTDI / serial problem Arvid Brodin
@ 2011-02-08 16:30 ` Arvid Brodin
0 siblings, 0 replies; 2+ messages in thread
From: Arvid Brodin @ 2011-02-08 16:30 UTC (permalink / raw)
To: kernelnewbies
Sorry, this was intended for the linux-usb list.
--
Arvid
Arvid Brodin wrote:
> Hi!
>
> I get weird problems when I use a null modem cable between the two ports
> on a FT232BM (2-port FTDI USB-to-serial converter) with an isp1761 host
> controller. The same thing does not happen with an EHCI host controller.
> Lengthy details follows:
>
> With the EHCI host controller:
> =============================
>
> [Terminal 1]
> $ cat /dev/ttyUSB1
>
> [Terminal 2]
> $ echo "Something seems wrong here" > /dev/ttyUSB0
> $ echo "Something seems wrong here" > /dev/ttyUSB0
>
> [Terminal 1]
> Something seems wrong here
>
> Something seems wrong here
>
> ^C
> $
>
> Observe the extra new line after the strings. I'm not sure if this is a
> bug in the ftdi driver, some other part of the serial subsystem, or if
> it is the result of some terminal setting; with a USB analyzer I observe
> the following sequence of packets (#-# == device-endpoint):
>
> 3-2 OUT: "Something seems wrong here"
> 3-2 OUT: 0x0D 0x0A
> 4-1 IN: 0x01 0x60 'S'
> 4-1 IN: 0x01 0x60 'o'
> ...
> 4-1 IN: 0x01 0x60 0x0D
> 4-1 IN: 0x01 0x60 0x0A
> 4-2 OUT: 'S' # The echo from the reading side starts here
> 4-2 OUT: 'o'
> ...
> 4-2 OUT: 0x0D 0x0A
> 4-2 OUT: 0x0D 0x0A # The newline pair is echoed twice - perhaps both
> 'CR' and 'NL' are converted to "CRNL" in the echo?
>
> Anyway, since 3-1 is never read, no feedback loop is created by the two
> echoing devices.
>
>
> With the isp1761 host controller, driver from 2.6.35.7 backported to
> 2.6.27.54 and modified for platform endianness:
> =============================
>
> [Terminal 1]
> $ cat /dev/ttyUSB1
>
> [Terminal 2]
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
>
> [Terminal 1]
> This is isp1761 and something is wrong
>
> This is isp1761 and something is wrong
>
> This is isp1761 and something is wrong
>
> This is isp1761 and something is wrong
>
> This is isp1761 and something is wrong
>
> and something is wrong
> (blank line x7)
> This is isp1761 and something is wrong
>
> ^C
> # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0
> # cat /dev/ttyUSB1
> is wrong
> (blank line x30 ca)
> TThis is isp1761 and something is wrong
>
> ^C
> #
>
> The exact look of the error differs, but it is quite easy to trigger by
> echoing text several times in a row; also breaking the "cat" execution,
> echoing some more text, and then starting cat again seems to trigger the
> error often.
>
> On the bus the traffic looks something like this:
>
> 7-2 OUT: "This is isp1761 and something is wrong"
> 7-2 OUT: 0x0D
> 7-2 OUT: 0x0A (NAK) # The CRNL pair is split here and the NL is not
> directly accepted by the device
> 7-2 OUT: 0x0A (NAK)
> Following this is lots and lots of "0x0A NAKs" intermixed with traffic
> that looks quite like the EHCI case except that much of the traffic has
> to be re-sent lots of times before it is accepted. The 0x0A is finally
> accepted after all text has been received by 8-1 and echoed from 8-2.
> This exact pattern is repeated every time text is written to the serial
> port.
>
> Device 8 receives the characters and echoes them back to 7-1 as in the
> EHCI case. But with isp1761, after a while device 7 for some reason
> starts echoing parts of the received echo-text back. My guess is that
> this should not happen since device 7 is never read from. Anyway, this
> creates a feedback loop which would be the source of the spurious
> characters in the "cat" run above and that sometimes is powerful enough
> to make the terminal unresponsible.
>
> I've been trying to figure this thing out for a while now but quite
> frankly I'm stumped; I can't figure out where and why things goes wrong.
> Any ideas are welcome! Perhaps the NAK problem/bug triggers a
> problem/bug somewhere in linux' serial terminal code?
>
> The terminal settings are the defaults and are the same during all
> examples above on both serial ports:
>
> $ stty -a -F /dev/ttyUSB0
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>;
> start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
> flush = ^O; 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
>
> $ stty -g -F /dev/ttyUSB0
> 500:5:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
>
> --
> Arvid Brodin
> Enea Services Stockholm AB
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-02-08 16:30 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-08 16:26 Another ISP1761 / FTDI / serial problem Arvid Brodin
2011-02-08 16:30 ` Arvid Brodin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.