Another ISP1761 / FTDI / serial problem

[arvid.brodin@enea.com (Arvid Brodin)]

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