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
