CH341 - Device recognized as /dev/USB0, but won't communicate

mezzmer · 02-06-2018, 03:11 PM

Hope one of the gurus here can help me. I've got a USB to serial adapter that I'm trying to get running on linux Mint. dmesg shows the device connected, I can toggle DTR with picocom, and statserial shows the device as active and responding when I do so.

The device seems to be functional, but I can't send/receive any serial data when I connect it to an SG300 switch console port. The same port works when I connect to a "real" serial port. I tested the USB2serial device on a Windows 8 machine, and it seems to be working.

I've done a lot of googleing, but most of the stuff is really ancient, and there was a kernel patch circulating in about 2007-9 or so. From what I can determine the ch341 is a pretty common chip, but I would suspect that should have made it to mainline by now if there was an issue.

I've posted some diagnostic output below:

Code:

$ uname -a
Linux host 4.4.0-91-generic #114-Ubuntu SMP Tue Aug 8 11:56:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

dmesg-on connection
[Feb 3 16:35] usb 1-14: new full-speed USB device number 37 using xhci_hcd
[  +0.128677] usb 1-14: New USB device found, idVendor=1a86, idProduct=7523
[  +0.000008] usb 1-14: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  +0.000005] usb 1-14: Product: USB2.0-Ser!
[  +1.128028] usbcore: registered new interface driver usbserial
[  +0.000033] usbcore: registered new interface driver usbserial_generic
[  +0.000027] usbserial: USB Serial support registered for generic
[  +0.026570] usbcore: registered new interface driver ch341
[  +0.000041] usbserial: USB Serial support registered for ch341-uart
[  +0.000027] ch341 1-14:1.0: ch341-uart converter detected
[  +0.001732] usb 1-14: ch341-uart converter now attached to ttyUSB0

$ lsusb
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

sudo cat   /proc/tty/driver/usbserial
usbserinfo:1.0 driver:2.0
0: module:ch341 name:"ch341-uart" vendor:1a86 product:7523 num_ports:1 port:0 path:usb-0000:00:14.0-12

statserial /dev/ttyUSB0

Device: /dev/ttyUSB0

Signal  Pin  Pin  Direction  Status  Full
Name    (25) (9)  (computer)         Name
-----   ---  ---  ---------  ------  -----
FG       1    -      -           -   Frame Ground
TxD      2    3      out         -   Transmit Data
RxD      3    2      in          -   Receive  Data
RTS      4    7      out         1   Request To Send
CTS      5    8      in          0   Clear To Send
DSR      6    6      in          0   Data Set Ready
GND      7    5      -           -   Signal Ground
DCD      8    1      in          0   Data Carrier Detect
DTR     20    4      out         1   Data Terminal Ready
RI      22    9      in          0   Ring Indicator

ferrari · 02-06-2018, 06:19 PM

Check that the ch341 driver has claimed this device...

Code:

usb-devicesusb-devices|awk '/1a86/' RS="\n\n"

https://unix.stackexchange.com/quest...serial-adapter

Also make sure that the TX and RX lines are correct. Sometimes a null-modem cable is needed to cross them.

FWIW, I have sometimes have needed to connect to Brocade switches and Mikrotik routers via a console cable, and always found my PL2303 usb-serial converter to be reliable.

mezzmer · 02-07-2018, 04:34 AM

Hi Ferrari, thanks for the quick reply, my answers are merged with yours below:

Quote:

Originally Posted by ferrari

Check that the ch341 driver has claimed this device...

Code:

usb-devices|awk '/1a86/' RS="\n\n"

https://unix.stackexchange.com/quest...serial-adapter

I patched your quote for the benefit of someone who may be referring to this post-it threw me off because I had never heard of usb-devices, so I learned something-thanks!

Here's the output from usb-devices:

Code:

T:  Bus=01 Lev=01 Prnt=01 Port=11 Cnt=02 Dev#=  6 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1a86 ProdID=7523 Rev=02.54
S:  Product=USB2.0-Ser!
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=96mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=02 Driver=ch341

I'm not sure what I'm looking for, but it looks OK to me.

Quote:

Originally Posted by ferrari

Also make sure that the TX and RX lines are correct. Sometimes a null-modem cable is needed to cross them.

Given that I was able to connect it to UPS under windows successfully, I think I'm safe to eliminate the wiring. I used picocom to explicitly set the baud rate and double checked that it was the same as the SG300. I tried a couple of times, so I'm pretty sure I did things correctly.

Quote:

Originally Posted by ferrari

FWIW, I have sometimes have needed to connect to Brocade switches and Mikrotik routers via a console cable, and always found my PL2303 usb-serial converter to be reliable.

I'll take that suggestion and order one from ebay. In the 3-4 weeks I'm going to be waiting for the slow boat from China, I'll keep struggling to get the CH341 working.

Any other suggestions?

ferrari · 02-07-2018, 12:08 PM

The 'usb-devices' command useful for determining which drivers are bound to particular devices, (similar to 'lspci -nnk' for PCI-connected devices). Anyway, that confirms that the appropriate driver is loaded.

Is the baud rate set appropriately? I usually connect using 'minicom -s',setting the /dev/ttyUSB[0,1,2...] device and appropriate baud rate there as well.

jefro · 02-07-2018, 03:29 PM

We might need to know distro and version.

However an older web pageCode:

sudo chmod 777 /dev/ttyUSB0
(make sure you enter the correct number but mostly for what I have seen is ttyUSB0. 0 is a zero) suggests permissions.

https://forums.linuxmint.com/viewtopic.php?t=135914

mezzmer · 02-07-2018, 05:51 PM

Thanks for the replies guys. I found an old Sportster 33.6 FaxModem lying around in the basement, and I was able to talk with it using the USB Serial, but I can't get the SG300 to talk to it. I wonder if it has something to do with flow control Something caused the statserial to change:

Code:

Device: /dev/ttyUSB0

Signal  Pin  Pin  Direction  Status  Full
Name    (25) (9)  (computer)         Name
-----   ---  ---  ---------  ------  -----
FG       1    -      -           -   Frame Ground
TxD      2    3      out         -   Transmit Data
RxD      3    2      in          -   Receive  Data
RTS      4    7      out         1   Request To Send
CTS      5    8      in          1   Clear To Send
DSR      6    6      in          1   Data Set Ready
GND      7    5      -           -   Signal Ground
DCD      8    1      in          0   Data Carrier Detect
DTR     20    4      out         1   Data Terminal Ready
RI      22    9      in          0   Ring Indicator

RTS/CTS/DTR are all one now. Modem must have done something to trigger it. For now it is even staying that way even though I've unplugged the modem. When I unplug the serial and plug it back in again CTS/DSR go back to 0 when I restart statserial.

Quote:

Originally Posted by ferrari

The 'usb-devices' command useful for determining which drivers are bound to particular devices, (similar to 'lspci -nnk' for PCI-connected devices). Anyway, that confirms that the appropriate driver is loaded.

Is the baud rate set appropriately? I usually connect using 'minicom -s',setting the /dev/ttyUSB[0,1,2...] device and appropriate baud rate there as well.

Quote:

Originally Posted by jefro

We might need to know distro and version.

However an older web pageCode:

sudo chmod 777 /dev/ttyUSB0
(make sure you enter the correct number but mostly for what I have seen is ttyUSB0. 0 is a zero) suggests permissions.

https://forums.linuxmint.com/viewtopic.php?t=135914

Thanks, I saw this... I think that has to do with permissions, but I put myself in the dialout group, so I have access to the modem already

I don't know if I did anything to "SOLVE" the issue or not. This thing now works with the modem but not the SG300, so I likely have a different problem.

ferrari · 02-07-2018, 06:02 PM

Yes, this doesn't read like a permissions issue, and device node ownership easily checked anyway...

Code:

ls -l /dev/ttyUSB*

A quick search on the SG300 shows that it expects 115200 (Default Baud Rate), 8 (data bits), N (no parity), 1 (stop bit), so I'd be checking that via minicom or similar. Usually flow control isn't needed/used for this type of situation.

ferrari · 02-07-2018, 06:16 PM

Since you mentioned that you're using picocom, try something like

Code:

picocom -b 115200 /dev/ttyUSB0

mezzmer · 02-07-2018, 07:57 PM

Thanks again ferrari... This problem has morphed because I have been able to communicate with an old USR FaxModem over the USB serial.

My problem is how to communicate with the SG300 - a "real serial port" works fine, but the USB doesn't. I'm wondering if it is because the SG300 isn't raising CTS/DTR lines?

I've copied your posts and answered them below:

Quote:

Originally Posted by ferrari

Yes, this doesn't read like a permissions issue, and device node ownership easily checked anyway...

Code:

ls -l /dev/ttyUSB*

A quick search on the SG300 shows that it expects 115200 (Default Baud Rate), 8 (data bits), N (no parity), 1 (stop bit), so I'd be checking that via minicom or similar. Usually flow control isn't needed/used for this type of situation.

I don't think it's permissions, because I had that issue earlier, and then I added myself to the dialout group and was able to access the device.

What I am curious about though is the difference between the USB and the onboard serial - what is 188, 0 vs 4, 64? Does that provide a hint as to what is happening?

Code:

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Feb  7 18:41 /dev/ttyUSB0
$ ls -l /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Feb  7 18:54 /dev/ttyS0

Quote:

Originally Posted by ferrari

Since you mentioned that you're using picocom, try something like

Code:

picocom -b 115200 /dev/ttyUSB0

I did, several times - I then went to the trouble of setting the SG300 to 9600 Baud with no auto sensing. The linux box wants to default to 9600 Baud, so I thought I'd nail the SG300 down and work from there. The SG300 talks over a real serial port very well.

One of the reasons I switched to picocom for testing is that it is easy to change baud rate and you get feedback messages when you do. ^A^U steps baud rate up and ^AD steps it down:

Code:

 $ picocom /dev/ttyUSB0
picocom v1.7

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 9600
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        :
omap is        :
emap is        : crcrlf,delbs,

Terminal ready

*** baud: 19200 ***

*** baud: 38400 ***

*** baud: 57600 ***

*** baud: 115200 ***

*** baud: 57600 ***

*** baud: 38400 ***

*** baud: 19200 ***

*** baud: 9600 ***

When I put a USR Fax modem on the USB serial and stepped the baud rate up and down I could type AT and the modem detected the change (sorry I didn't keep a copy of the session), and replied back OK. I was able to verify the speed with another AT command (don't remember which one). I know the USB Serial is changing speed and given the right circumstances can communicate.

I came across stty when I was looking - does this give you any insight?

Code:

#
#  USB Serial
#

$ stty -F /dev/ttyUSB0 -a
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; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar 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 -flusho -extproc

#
#  Real Serial Port
#
$ stty -F /dev/ttyS0 -a
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; discard = ^O;
min = 1; time = 5;
-parenb -parodd -cmspar 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 -flusho -extproc

Thanks again for all your help.

ferrari · 02-07-2018, 10:20 PM

Quote:

I don't think it's permissions, because I had that issue earlier, and then I added myself to the dialout group and was able to access the device.

No, it isn't a permissions problem, and you already mentioned that you had added the user to the dialout group anyway.

Quote:

My problem is how to communicate with the SG300 - a "real serial port" works fine, but the USB doesn't. I'm wondering if it is because the SG300 isn't raising CTS/DTR lines?

I wouldn't that thought this matters as those control lines are used for hardware flow control when implemented, and the default for the SG300 (as with most of these console devices) is not to use/require them. Having TX, RX, and GND should be all that's required IMHO. I could be wrong about that though.

Quote:

What I am curious about though is the difference between the USB and the onboard serial - what is 188, 0 vs 4, 64? Does that provide a hint as to what is happening?

Don't concern yourself with those. The are major and minor device numbers and it is down to the driver as to how they are used. (Usually just to differentiate different instances eg multiple devices supported by same driver.)

Some more research needed I guess.

mezzmer · 02-07-2018, 10:42 PM

Quote:

Originally Posted by ferrari

Some more research needed I guess.

Any suggestions as to where I should start?

ferrari · 02-07-2018, 10:45 PM

Turning my attention to the SG300...I have found some devices only provide an active console when a device is attached to the serial port at boot (of the switch). I don't know whether you're in a situation where you can do this?

ferrari · 02-07-2018, 10:50 PM

This reference suggests that hitting 'Enter' will initiate a console session with a login prompt presented...

Quote:

Step 15. Hit Enter on the keyboard to activate the Command Line Interface (CLI). The log in prompt is displayed:

https://sbkb.cisco.com/CiscoSB/GetAr...=2&converted=0

mezzmer · 02-07-2018, 11:03 PM

Quote:

Originally Posted by ferrari

Turning my attention to the SG300...I have found some devices only provide an active console when a device is attached to the serial port at boot (of the switch). I don't know whether you're in a situation where you can do this?

I understand what you are saying, and for some devices that's true, but it's not true for the SG300 because I have been moving the connection back and forth between the "real" serial and the USB Serial. It always works on the "real" serial, so I know it's active.

Any other ideas/suggestions?

ferrari · 02-07-2018, 11:21 PM

If sending an 'Enter' character doesn't wake up the device then I think it may well be due to a voltage level issue perhaps (needed to distinguish between high and low states). It may be that if the switch was power cycled you'd then see characters presented, but the serial console would be 'deaf' to characters sent from the PC if signal voltage levels are insufficient.