Likely issue with ch341 kernel-module/driver

Likely issue with ch341 kernel-module/driver

[Ajay Garg]

Hi all.

I am attaching the RS232-TTL via a serial-USB converter on my machine.

However, when I connect a putty-session with my embedded-device, I see
strange issues (garbage characters transmitted from embedded-device to
putty; nothing can be read from putty into embedded-device).

It seems that there is some issue with the driver.
Lots of these lines are seen in dmesg ::


########################################################################################
[ 8657.022997] ch341-uart ttyUSB0:
usb_serial_generic_read_bulk_callback - nonzero urb status: -71
########################################################################################



Other informations ::

########################################################################################
ajay@ajay-HP-15-Notebook-PC:~$ lsusb
Bus 001 Device 002: ID 8087:8001 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 05c8:036e Cheng Uei Precision Industry Co., Ltd (Foxlink)
Bus 002 Device 002: ID 0bda:b001 Realtek Semiconductor Corp.
Bus 002 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
########################################################################################


########################################################################################
ajay@ajay-HP-15-Notebook-PC:~$ lsmod | grep ch341
ch341                  13761  1
usbserial              38972  3 ch341
########################################################################################


########################################################################################
ajay@ajay-HP-15-Notebook-PC:~$ uname -a
Linux ajay-HP-15-Notebook-PC 3.16.0-30-generic #40~14.04.1-Ubuntu SMP
Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux
########################################################################################



Any chance this can be made to work? Any upgrade that might solve the issue?
We will be grateful for ideas.


Thanks and Regards,
Ajay

Re: Likely issue with ch341 kernel-module/driver

[Johan Hovold]

[ +CC: linux-usb ]

On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote:
> Hi all.
> 
> I am attaching the RS232-TTL via a serial-USB converter on my machine.
> 
> However, when I connect a putty-session with my embedded-device, I see
> strange issues (garbage characters transmitted from embedded-device to
> putty; nothing can be read from putty into embedded-device).
> 
> It seems that there is some issue with the driver.

Why do think it's a driver issue?

> Lots of these lines are seen in dmesg ::
> 
> 
> ########################################################################################
> [ 8657.022997] ch341-uart ttyUSB0:
> usb_serial_generic_read_bulk_callback - nonzero urb status: -71
> ########################################################################################
> 
> 
> 
> Other informations ::
> 
> ########################################################################################
> ajay@ajay-HP-15-Notebook-PC:~$ lsusb
> Bus 001 Device 002: ID 8087:8001 Intel Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 002 Device 003: ID 05c8:036e Cheng Uei Precision Industry Co., Ltd (Foxlink)
> Bus 002 Device 002: ID 0bda:b001 Realtek Semiconductor Corp.
> Bus 002 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> ########################################################################################
> 
> 
> ########################################################################################
> ajay@ajay-HP-15-Notebook-PC:~$ lsmod | grep ch341
> ch341                  13761  1
> usbserial              38972  3 ch341
> ########################################################################################
> 
> 
> ########################################################################################
> ajay@ajay-HP-15-Notebook-PC:~$ uname -a
> Linux ajay-HP-15-Notebook-PC 3.16.0-30-generic #40~14.04.1-Ubuntu SMP
> Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux
> ########################################################################################
> 
> 
> 
> Any chance this can be made to work? Any upgrade that might solve the issue?
> We will be grateful for ideas.

This is a known issue with your device that has been reported in this
thread:

	https://lkml.kernel.org/r/CAF3ayyDe44POd1NoSBqn_gjA8XLoK3r_getDYnWx+a_1rL0r5g@mail.gmail.com

Looks like a hardware issue, I'm afraid.

Johan

Re: Likely issue with ch341 kernel-module/driver

[Peter Stuge]

Johan Hovold wrote:
> On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote:
..
> > garbage characters transmitted from embedded-device
..
> > It seems that there is some issue with the driver.
> 
> Why do think it's a driver issue?

I can confirm similar issues with the in-tree driver and my hardware.


> > Any chance this can be made to work?

Ajay, please try building the vendor driver. That works well for me.


> > Any upgrade that might solve the issue?

There is no upgrade. Someone needs to spend a day or so on adding
functionality from the vendor driver to the in-tree driver, in a
backwards-compatible way.


> Looks like a hardware issue, I'm afraid.

When I got garbage from the in-tree driver it was indeed a driver issue.


//Peter

Re: Likely issue with ch341 kernel-module/driver

[Johan Hovold]

On Wed, Aug 26, 2015 at 08:09:30PM +0200, Peter Stuge wrote:
> Johan Hovold wrote:
> > On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote:
> ..
> > > garbage characters transmitted from embedded-device
> ..
> > > It seems that there is some issue with the driver.
> > 
> > Why do think it's a driver issue?
> 
> I can confirm similar issues with the in-tree driver and my hardware.

What hardware is that?

> > > Any chance this can be made to work?
> 
> Ajay, please try building the vendor driver. That works well for me.

Yes, please do.

> > > Any upgrade that might solve the issue?
> 
> There is no upgrade. Someone needs to spend a day or so on adding
> functionality from the vendor driver to the in-tree driver, in a
> backwards-compatible way.
> 
> > Looks like a hardware issue, I'm afraid.
> 
> When I got garbage from the in-tree driver it was indeed a driver issue.

That's good to hear. Care to write up a patch? :)

Thanks,
Johan 

Re: Likely issue with ch341 kernel-module/driver

[Ajay Garg]

I started in the morning to build the driver from the source provided
by the vendor, but it was written in the times of kernel-version 2.4,
and I got hopelessly stuck.

Wanting to take a break, I reset my setup, and VERY strangely, what I
now observe is ::

a)
I am NOT able to send anything from the embedded-system to
putty-session (nothing appears at all on the putty session).

b)
Receive is working perfectly (anything I type in the putty-session is
received fine in the embedded-application).


Not sure what the hell is going on :(

Also, as per http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
the particular serial-USB-adapter device is added into the id_table,
so seems supported as per say.


Additionally, the message has changed to

###########################################################
usb 2-2: device not accepting address 8, error -71
###########################################################



Completely lost :(

On Wed, Aug 26, 2015 at 11:45 PM, Johan Hovold <johan@kernel.org> wrote:
> On Wed, Aug 26, 2015 at 08:09:30PM +0200, Peter Stuge wrote:
>> Johan Hovold wrote:
>> > On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote:
>> ..
>> > > garbage characters transmitted from embedded-device
>> ..
>> > > It seems that there is some issue with the driver.
>> >
>> > Why do think it's a driver issue?
>>
>> I can confirm similar issues with the in-tree driver and my hardware.
>
> What hardware is that?
>
>> > > Any chance this can be made to work?
>>
>> Ajay, please try building the vendor driver. That works well for me.
>
> Yes, please do.
>
>> > > Any upgrade that might solve the issue?
>>
>> There is no upgrade. Someone needs to spend a day or so on adding
>> functionality from the vendor driver to the in-tree driver, in a
>> backwards-compatible way.
>>
>> > Looks like a hardware issue, I'm afraid.
>>
>> When I got garbage from the in-tree driver it was indeed a driver issue.
>
> That's good to hear. Care to write up a patch? :)
>
> Thanks,
> Johan



-- 
Regards,
Ajay

Re: Likely issue with ch341 kernel-module/driver

[Johan Hovold]

[ Please avoid top-posting. ]

On Thu, Aug 27, 2015 at 12:13:32PM +0530, Ajay Garg wrote:
> I started in the morning to build the driver from the source provided
> by the vendor, but it was written in the times of kernel-version 2.4,
> and I got hopelessly stuck.

The vendor driver is only for 2.4? Peter?

> Wanting to take a break, I reset my setup, and VERY strangely, what I
> now observe is ::
> 
> a)
> I am NOT able to send anything from the embedded-system to
> putty-session (nothing appears at all on the putty session).
> 
> b)
> Receive is working perfectly (anything I type in the putty-session is
> received fine in the embedded-application).
> 
> 
> Not sure what the hell is going on :(

Did you enable hardware flow control somewhere perhaps?

> Also, as per http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
> the particular serial-USB-adapter device is added into the id_table,
> so seems supported as per say.

That id was added by 82078234d402 ("USB: serial: ch341: New VID/PID for
CH341 USB-serial") in 2008, which claims that the driver supports both
old and new devices.

> Additionally, the message has changed to
> 
> ###########################################################
> usb 2-2: device not accepting address 8, error -71
> ###########################################################

This still looks like a hardware issue to me. Specifically, this happens
before the ch341 driver is even involved.

> Completely lost :(

Try to see if you can get the device to work reliably with some other
driver (vendor driver or other OS) to rule out a broken device. 

Thanks,
Johan

Re: Likely issue with ch341 kernel-module/driver

[Ajay Garg]

Hi John.

On Thu, Aug 27, 2015 at 1:07 PM, Johan Hovold <johan@kernel.org> wrote:
>
> Try to see if you can get the device to work reliably with some other
> driver (vendor driver or other OS) to rule out a broken device.
>

I tested the serial-usb adapter using a loopback-hardware-tool
(confirmed to be perfect).
Using this, I see what I type, echo it back, and see what I receive.

The putty session-settings are standard one - 9600, 8N-1, no parity.


The byte flow is
putty-on-laptop => usb-interface => serial-interface => loopback =>
serial-interface => usb-interface => putty-on-laptop.

Thereafter, following are the echo-sequences I see ::

a ==> 0
b ==> '
c ==> N



This (I guess) confirms a problem on (at least) the driver-side.

Thanks everyone for the quick replies so far, I am grateful.


Thanks and Regards,
Ajay

Re: Likely issue with ch341 kernel-module/driver

[Johan Hovold]

On Thu, Aug 27, 2015 at 01:57:01PM +0530, Ajay Garg wrote:
> Hi John.
> 
> On Thu, Aug 27, 2015 at 1:07 PM, Johan Hovold <johan@kernel.org> wrote:
> >
> > Try to see if you can get the device to work reliably with some other
> > driver (vendor driver or other OS) to rule out a broken device.
> >
> 
> I tested the serial-usb adapter using a loopback-hardware-tool
> (confirmed to be perfect).
>
> Using this, I see what I type, echo it back, and see what I receive.
> 
> The putty session-settings are standard one - 9600, 8N-1, no parity.
> 
> The byte flow is
> putty-on-laptop => usb-interface => serial-interface => loopback =>
> serial-interface => usb-interface => putty-on-laptop.
>
> Thereafter, following are the echo-sequences I see ::
> 
> a ==> 0
> b ==> '
> c ==> N
> 
> This (I guess) confirms a problem on (at least) the driver-side.

Not unless you confirm that the same setup works when using a different
driver, right? Otherwise, it could still be a hw issue.

Johan

Re: Likely issue with ch341 kernel-module/driver

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Johan Hovold wrote:
> > I started in the morning to build the driver from the source provided
> > by the vendor, but it was written in the times of kernel-version 2.4,
> > and I got hopelessly stuck.
> 
> The vendor driver is only for 2.4? Peter?

http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
http://www.wch.cn/downfile/177

The vendor driver version 1.2 readme.txt from 2014-10-10 says:

Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x

It didn't build immediately against the kernel I had at hand, but with
a small touchup (patch attached) it built fine against a 3.10 kernel.


> > Also, as per http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
> > the particular serial-USB-adapter device is added into the id_table,
> > so seems supported as per say.
> 
> That id was added by 82078234d402 ("USB: serial: ch341: New VID/PID for
> CH341 USB-serial") in 2008, which claims that the driver supports both
> old and new devices.

My hardware has that same VID/PID, but there is a version request
sent to the device and my version number is quite a bit higher (20-30)
than what is mentioned in the in-tree driver comments; I guess the
protocol grew with newer versions of the device, but VID/PID weren't
updated. I'm sure it's possible to have a backwards-compatible
driver, but the vendor driver differs enough from the in-tree driver
that I can't be confident that simply doing what the vendor driver
does will work also on older versions of the device.


> > ###########################################################
> > usb 2-2: device not accepting address 8, error -71
> > ###########################################################
> 
> This still looks like a hardware issue to me. Specifically, this happens
> before the ch341 driver is even involved.

I haven't seen any messages like this with my hardware.


//Peter

[-- Attachment #2: touchup-ch34x.c-version-1.2-for-linux-3.10.patch --]
[-- Type: text/plain, Size: 5313 bytes --]

--- ch34x.c.orig	2014-04-14 10:38:44.000000000 +0200
+++ ch34x.c	2015-06-15 19:26:39.000000000 +0200
@@ -10,11 +10,7 @@
 // Support linux kernel version 2.6.25 and later
 //
 
-#include <linux/version.h>
-#ifndef KERNEL_VERSION
-#define	KERNEL_VERSION(ver, rel, seq)	((ver << 16) | (rel << 8) | (seq))
-#endif
-
+#include <generated/uapi/linux/version.h>
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -380,7 +376,7 @@
 	unsigned char reg_value = 0;
 	unsigned short value = 0;
 	unsigned short index = 0;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -405,7 +401,7 @@
 		return;
 
 	cflag = termios->c_cflag;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s (%d) cflag=0x%x\n", __func__, port->number, cflag);
 #else
 	dbg_ch34x("%s (%d) cflag=0x%x\n", __func__, port->port_number, cflag);
@@ -515,7 +511,7 @@
 	/*unsigned int msr;*/
 	unsigned int retval;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -561,7 +557,7 @@
 	long timeout;
 	wait_queue_t wait;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -636,7 +632,7 @@
 	struct usb_serial *serial = port->serial;
 	int retval;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number );
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number );
@@ -710,7 +706,7 @@
 	/*unsigned int mcr = priv->line_control;*/
 	u8 control;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -743,7 +739,7 @@
 	unsigned int status;
 	unsigned int changed;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s -port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s -port:%d", __func__, port->port_number);
@@ -793,7 +789,7 @@
 {
 	//struct usb_serial_port *port = tty->driver_data;
 #endif
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d, cmd=0x%04x", __func__, port->number, cmd);
 #else
 	dbg_ch34x("%s - port:%d, cmd=0x%04x", __func__, port->port_number, cmd);
@@ -802,7 +798,7 @@
 	{
 		// Note here 
 		case TIOCMIWAIT:
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 			dbg_ch34x("%s - port:%d TIOCMIWAIT", __func__, port->number);
 #else
 			dbg_ch34x("%s - port:%d TIOCMIWAIT", __func__, port->port_number);
@@ -824,7 +820,7 @@
 	struct ch34x_private *priv = usb_get_serial_port_data( port );
 	unsigned long flags;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -877,7 +873,7 @@
 	struct ch34x_private *priv = usb_get_serial_port_data(port);
 	unsigned long flags;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d, %d bytes", __func__, port->number, count);
 #else
 	dbg_ch34x("%s - port:%d, %d bytes", __func__, port->port_number, count);
@@ -907,7 +903,7 @@
 	int room = 0;
 	unsigned long flags;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -933,7 +929,7 @@
 	int chars = 0;
 	unsigned long flags;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number);
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -1043,7 +1039,7 @@
 	int status = urb->status;
 	int retval;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s port:%d", __func__, port->number );
 #else
 	dbg_ch34x("%s port:%d", __func__, port->port_number );
@@ -1091,7 +1087,7 @@
 	u8 line_status;
 	char tty_flag;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number );
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -1197,7 +1193,7 @@
 	int retval;
 	int status = urb->status;
 
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
 	dbg_ch34x("%s - port:%d", __func__, port->number );
 #else
 	dbg_ch34x("%s - port:%d", __func__, port->port_number );