problems with ch341 driver USB RS485 in Linux but not Windows

problems with ch341 driver USB RS485 in Linux but not Windows

[John Paul Morrison]

Hi

I have a few CH340/341 USB RS485 adapters - they all look identical
and use the ch341 driver with ID 1a86:7523 but I've found one that
reports a different iProduct and bcdDevice from the others. They all
work fine in Windows but one has problems transmitting in Linux.

I have tried this on a few different machines/kernels.
5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64
5.10.92-v7+ #1514 SMP Mon Jan 17 17:36:39 GMT 2022 armv7l
5.10.93.2-microsoft-standard-WSL2 #2 SMP Sat Mar 5 13:40:04 PST 2022 x86_64

miniterm and dmesg offer some clues - the problem device shows
different CTS/DSR states
I have not been able to work around this with stty or in miniterm

problem device
miniterm
--- RTS: active    DTR: active    BREAK: inactive
--- CTS: inactive  DSR: inactive  RI: inactive  CD: inactive
--- software flow control: inactive
--- hardware flow control: inactive

In Windows the Termite com program shows CTS/DSR/RI/CD active
If I run socat in Windows sharing the serial port, and socat Linux
using a pty the Linux serial application works perfectly but fails
using the ch341 driver directly

dmesg
[702953.276954] usb 3-4: new full-speed USB device number 2 using xhci_hcd
[702953.426006] usb 3-4: New USB device found, idVendor=1a86,
idProduct=7523, bcdDevice= 2.63
[702953.426014] usb 3-4: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[702953.426017] usb 3-4: Product: USB2.0-Serial
[702953.426919] ch341 3-4:1.0: ch341-uart converter detected
[702953.427336] usb 3-4: ch341-uart converter now attached to ttyUSB1


working device
miniterm
--- RTS: active    DTR: active    BREAK: inactive
--- CTS: active    DSR: active    RI: active    CD: active
--- software flow control: inactive
--- hardware flow control: inactive

dmesg
[  699.616711] usb 1-1.4: new full-speed USB device number 7 using ehci-pci
[  699.726105] usb 1-1.4: New USB device found, idVendor=1a86,
idProduct=7523, bcdDevice= 2.54
[  699.726113] usb 1-1.4: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[  699.726117] usb 1-1.4: Product: USB2.0-Ser!
[  699.726517] ch341 1-1.4:1.0: ch341-uart converter detected
[  699.727292] ch341-uart ttyUSB0: break control not supported, using
simulated break
[  699.727411] usb 1-1.4: ch341-uart converter now attached to ttyUSB0


lsusb - same vendor id
Bus 001 Device 007: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

lsusb -v
The only difference is in bcdDevice, iProduct and MaxPower

problem device
Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x1a86 QinHeng Electronics
  idProduct          0x7523 HL-340 USB-Serial adapter
  bcdDevice            2.63
  iManufacturer           0
  iProduct                2 USB2.0-Serial
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               98mA


working device
Bus 001 Device 007: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x1a86 QinHeng Electronics
  idProduct          0x7523 HL-340 USB-Serial adapter
  bcdDevice            2.54
  iManufacturer           0
  iProduct                2 USB2.0-Ser!
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               96mA

Re: problems with ch341 driver USB RS485 in Linux but not Windows

[Johan Hovold]

On Sun, Mar 06, 2022 at 05:40:36PM -0800, John Paul Morrison wrote:
> Hi
> 
> I have a few CH340/341 USB RS485 adapters - they all look identical
> and use the ch341 driver with ID 1a86:7523 but I've found one that
> reports a different iProduct and bcdDevice from the others. They all
> work fine in Windows but one has problems transmitting in Linux.
>
> I have tried this on a few different machines/kernels.
> 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64
> 5.10.92-v7+ #1514 SMP Mon Jan 17 17:36:39 GMT 2022 armv7l
> 5.10.93.2-microsoft-standard-WSL2 #2 SMP Sat Mar 5 13:40:04 PST 2022 x86_64
> 
> miniterm and dmesg offer some clues - the problem device shows
> different CTS/DSR states
> I have not been able to work around this with stty or in miniterm
> 
> problem device
> miniterm
> --- RTS: active    DTR: active    BREAK: inactive
> --- CTS: inactive  DSR: inactive  RI: inactive  CD: inactive
> --- software flow control: inactive
> --- hardware flow control: inactive
> 
> In Windows the Termite com program shows CTS/DSR/RI/CD active
> If I run socat in Windows sharing the serial port, and socat Linux
> using a pty the Linux serial application works perfectly but fails
> using the ch341 driver directly
> 
> dmesg
> [702953.276954] usb 3-4: new full-speed USB device number 2 using xhci_hcd
> [702953.426006] usb 3-4: New USB device found, idVendor=1a86,
> idProduct=7523, bcdDevice= 2.63
> [702953.426014] usb 3-4: New USB device strings: Mfr=0, Product=2,
> SerialNumber=0
> [702953.426017] usb 3-4: Product: USB2.0-Serial
> [702953.426919] ch341 3-4:1.0: ch341-uart converter detected
> [702953.427336] usb 3-4: ch341-uart converter now attached to ttyUSB1

So it seems you've come across a device that uses a different protocol.
The CH340 I have here also has bcdDevice set to 2.54 as your working
device below do.

What chip version is the driver reporting if you enable debugging? For
example, using:

	echo module ch341 +p > /sys/kernel/debug/dynamic_debug/control

I have "Chip version: 0x30" here. Do you see any message about "break
control not supported" during probe?

You mention that modem status reporting and transmit doesn't work, but
what about receive?

I'm afraid I can't suggest much else but possibly trying to trace the
USB requests that Windows driver uses and see if you can confirm any
differences and if needed reverse engineer the new protocol.
 
> working device
> miniterm
> --- RTS: active    DTR: active    BREAK: inactive
> --- CTS: active    DSR: active    RI: active    CD: active
> --- software flow control: inactive
> --- hardware flow control: inactive
> 
> dmesg
> [  699.616711] usb 1-1.4: new full-speed USB device number 7 using ehci-pci
> [  699.726105] usb 1-1.4: New USB device found, idVendor=1a86,
> idProduct=7523, bcdDevice= 2.54
> [  699.726113] usb 1-1.4: New USB device strings: Mfr=0, Product=2,
> SerialNumber=0
> [  699.726117] usb 1-1.4: Product: USB2.0-Ser!
> [  699.726517] ch341 1-1.4:1.0: ch341-uart converter detected
> [  699.727292] ch341-uart ttyUSB0: break control not supported, using
> simulated break
> [  699.727411] usb 1-1.4: ch341-uart converter now attached to ttyUSB0

Johan

Re: problems with ch341 driver USB RS485 in Linux but not Windows

[Johan Hovold]

On Sat, Apr 23, 2022 at 03:51:46PM -0700, John Paul Morrison wrote:
> Hi Johan
> 
> This is the debugging output from the problem device - the chip version
> does not match and there's no break message or quirk flags.
> I compared the circuit boards and the problem device has a 12 MHz crystal
> and the chip is labelled  WCH CH340G.
> The working device doesn't have a crystal and the chip is unmarked or
> scrubbed. The circuit boards and construction appear the same.
> 
> Comparing datasheets the 340 requires an external crystal while the 341 can
> use an internal oscillator, so the working devices have a 341 of some sort.
> 
> I'll try a usbpcap/wireshark of the windows device - anything to look for?

Compare the control requests sent during probe and open with those of
the working device. In theory the bulk data could also packaged
differently but start with looking at the control requests.

You never answered my question on how this device is failing to work.
Is receive working at all? Do you see anything being transmitted even if
garbled?

> Another question - the CH340/341 datasheets list the maximum speed as 2
> Mbps, and the MAX485 line diver says it can do 2.5 Mbps.
> I have not been able to get them to work at 2 Mbps with either Linux or
> Windows but they work at 1.5 Mbps.
> Data is completely corrupted at 2 Mbps as if the baud rate is mismatched.
> Curious if anyone has these working above 1.5 Mbps.

I'm pretty sure we got both 2 Mbps and 3 Mbps to work accurately (at
least at TTL level). See commit 35714565089e ("USB: serial: ch341:
reimplement line-speed handling") that went into v5.5.

> [2419514.614782] usb 3-3.1: new full-speed USB device number 34 using
> xhci_hcd
> [2419514.821688] usb 3-3.1: New USB device found, idVendor=1a86,
> idProduct=7523, bcdDevice= 2.63
> [2419514.821694] usb 3-3.1: New USB device strings: Mfr=0, Product=2,
> SerialNumber=0
> [2419514.821697] usb 3-3.1: Product: USB2.0-Serial
> [2419514.831394] ch341 3-3.1:1.0: ch341-uart converter detected
> [2419514.831434] usb 3-3.1: ch341_control_in - (5f,0000,0000,2)
> [2419514.832185] usb 3-3.1: Chip version: 0x31

Note that the CH340G I have is here working correctly, but the chip
version is reported as 0x30 like your functioning device.

> [2419514.832190] usb 3-3.1: ch341_control_out - (a1,0000,0000)
> [2419514.832680] usb 3-3.1: ch341_control_out - (9a,1312,b282)
> [2419514.833181] usb 3-3.1: ch341_control_out - (9a,2518,00c3)
> [2419514.833685] usb 3-3.1: ch341_control_out - (a4,ffff,0000)
> [2419514.834987] usb 3-3.1: ch341-uart converter now attached to ttyUSB0

Johan