kern/70523: umct sending/receiving wrong characters
Brian Candler
B.Candler at pobox.com
Mon Aug 16 01:40:33 PDT 2004
>Number: 70523
>Category: kern
>Synopsis: umct sending/receiving wrong characters
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Aug 16 08:40:33 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Brian Candler
>Release: FreeBSD 5.2.1-RELEASE i386
>Organization:
>Environment:
I have the same occuring on two different systems:
FreeBSD 5.2.1-RELEASE #1: Tue Mar 30 11:09:14 BST 2004
CPU: AMD Athlon(tm) XP 2500+ (1837.51-MHz 686-class CPU)
ohci0: <OHCI (generic) USB controller> mem 0xee084000-0xee084fff irq 10 at device 2.0 on pci0
FreeBSD 4.10-RELEASE #0: Sun Aug 15 20:22:15 BST 2004
CPU: Pentium/P55C (quarter-micron) (263.93-MHz 586-class CPU)
uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xfcc0-0xfcdf irq 9 at device 7.2 on pci0
The first is a desktop, the second a Sony Vaio PCG-C1F laptop.
Since I get identical results, I'm pretty sure it's the umct driver which
has the problem.
>Description:
I plug in a 'Intel USB Solution USB-232' cable (USB to DB25). It identifies as:
ucom0: MCT Corporation. USB-232 Interfact Controller, rev 1.00/1.02, addr 3
(sic - Interfact not Interface)
However it consistently reads incorrect characters. Connecting back-to-back
with a real COM port, and using:
cu -l ucom0 -s 19200
cu -l cuaa0 -s 19200
* REAL COM PORT --> USB-232
If I send a space (20) I receive hex E8. If I send a capital A (41) I
receive hex E0. It's perfectly consistent, here's a mapping:
tx 20 30 31 32 33 34 35 36 37 38 39
rx e8 ec ec ed ed ee ee ef ef ec ec
tx 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
rx e0 e0 e1 e1 e2 e2 e3 e3 e0 e0 e1 e1 e2 e2 e3 e3
tx 50 51 52 53 54 55 56 57 58 59 5a
rx e4 e4 e5 e5 e6 e6 e7 e7 e4 e4 e5
* USB-232 --> REAL COM PORT
This time I get two bytes on the COM port for each byte I send on the USB232.
tx 20 30 31 32 33
rx 00FC C0FC C3FC C4FC or CCFC C7FC or CFFC
It does look rather a bit like speed mismatch (esp. USB-232 -> REAL), but I
tried different speed combinations and couldn't get them to talk.
I have not yet had a chance to try this device on a Linux box to see if
their mct_u232 driver works with it.
At 2400bps I managed to freeze the laptop totally, requiring me to remove
the battery and reboot. However that also happens with a different [uplcom]
USB->RS232 adaptor I have as well, so that's a subject of a different PR.
>How-To-Repeat:
See above. You need 'kldload umct', a genuine serial port, and a null-modem
serial cable. Run 'cu' at both ends (under 'script' if you want to catch the
data and use 'hexdump -C' to view it afterwards). I also have a little C
protocol-analyser program to view bytes directly in hex.
>Fix:
No idea! Would like to know if anyone else has a USB<->RS232 device which
uses the umct driver working successfully.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list