Serial CDC-ACM not working on Linux and Windows

[romainreignier]

As mentioned on Discord, the Ollie-V2 is detected by the Linux kernel as 5 CDC-ACM USB interfaces. 4 for the CH344 (serial ports) and one for the CAN microcontroler:

[ 6060.600696] usb 1-1: new high-speed USB device number 10 using xhci_hcd
[ 6060.756877] usb 1-1: New USB device found, idVendor=1a86, idProduct=8091, bcdDevice= 2.10
[ 6060.756883] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 6060.756886] usb 1-1: Product: USB HUB
[ 6060.758356] hub 1-1:1.0: USB hub found
[ 6060.758378] hub 1-1:1.0: 4 ports detected
[ 6061.056784] usb 1-1.1: new high-speed USB device number 11 using xhci_hcd
[ 6061.165101] usb 1-1.1: New USB device found, idVendor=1a86, idProduct=55d5, bcdDevice=80.46
[ 6061.165121] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6061.165133] usb 1-1.1: Product: USB Quad_Serial
[ 6061.165138] usb 1-1.1: Manufacturer: wch.cn
[ 6061.165143] usb 1-1.1: SerialNumber: 0123456789
[ 6061.174444] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
[ 6061.175330] cdc_acm 1-1.1:1.2: ttyACM1: USB ACM device
[ 6061.176133] cdc_acm 1-1.1:1.4: ttyACM2: USB ACM device
[ 6061.177155] cdc_acm 1-1.1:1.6: ttyACM3: USB ACM device
[ 6061.260680] usb 1-1.2: new high-speed USB device number 12 using xhci_hcd
[ 6061.361515] usb 1-1.2: New USB device found, idVendor=16d0, idProduct=1261, bcdDevice= 1.00
[ 6061.361519] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6061.361521] usb 1-1.2: Product: MeatPi Dual CAN
[ 6061.361522] usb 1-1.2: Manufacturer: MeatPi
[ 6061.361524] usb 1-1.2: SerialNumber: cdab6b574ebc86bf
[ 6061.364570] cdc_acm 1-1.2:1.0: ttyACM4: USB ACM device

But I cannot manage to send data through any of the 4 serial ports. The Green and Red lights do not blink and using a scope or doing a wire loop between Tx and Rx on RS-232 or UART ports, nothing is sent.

The CH344 is advertised as a CDC-ACM compliant device.

Using the manufacturer provided ch343 driver works but it requires a manual installation of an external driver which is not ideal.

I have noticed the same on Windows. Using the CH343 driver work but forcing the default Serial Driver does not work.

Did you manage to use the standard CDC-ACM driver? At least, your README should explain the situation for Linux (I see that you Windows driver uses the CH343 driver).

Tested on Windows 10, Ubuntu 22.04 with kernels 5.15 and 6.2, ArchLinux with kernel 6.6, Alpine Linux 3.8 with kernel 6.1.

[meatpiHQ]

@romainreignier Interesting, it works fine for me. I'm running a virtual machine and I can use it without installing any drivers.`

Ubuntu 18.04.3 LTS Kernel 5.4.0-150

[meatpiHQ]

@romainreignier I've just tested another fresh VM and it also works ok.

ubuntu-22.04.3 Kernel 6.5.0

[romainreignier]

Thanks for testing. Which software did you use? I have used picocom.

[romainreignier]

I have tried with minicom and picocom on an old Ubuntu 16.04 with 4.15 kernel but the result is the same.

[meatpiHQ]

Thanks for testing. Which software did you use? I have used picocom.

I used screen, and I had TX RX looped. Nothing special in my setup.

Just to confirm you've set the right permissions?

[meatpiHQ]

I have tried with minicom and picocom on an old Ubuntu 16.04 with 4.15 kernel but the result is the same.

I assume you're using a VM?

[romainreignier]

Just to confirm you've set the right permissions?

No, I have used sudo.

I assume you're using a VM?

No, an old PC

[romainreignier]

I have tried with the correct dialout group and with screen without success. I have also tried in a VirtualBox VM with Debian 12 OS and USB 1.1 Controller and nothing changed.

[romainreignier]

I have tried a Debian 12 VM on a Windows 10 host and I get interesting results.

1. If I use the generic Windows "Serial Driver" on the Windows Host (forced in the Device Manager), start the VM and enable the USB, then I have the same issue, no character sent.
2. If I switch to the CH344 driver in Windows Device Manager (without opening the serial port in a terminal application), start the VM and enable the USB Device, then, this time, the communication works 🎉

So, it seems to me that the Manufacturer Driver do something to init the chip and then after, it starts working in standard CDC-ACM driver.

[romainreignier]

And on a Linux HOST using the WCH 343 driver, the serial port needs to be opened once before it works in a Linux VM with the CDC-ACM default driver.

[meatpiHQ]

@romainreignier is it possible that flow control is somehow being enabled ?

Seems like I need to contact wch for support about this issue.

[jamesturton]

Removing R20 worked for me using the default cdc_acm driver.

R20 is pulling down the CFG pin which enables hardware flow control. The RS-232 port on the Ollie does not support HW flow control however, so it will never work without forcing the ch344 to use software flow control. The ch343ser driver does this and changes the ch344 to use software flow control, but the cdc_acm does not.

From the datasheet:

[meatpiHQ]

@jamesturton Good catch! I confirm removing R20 works.

[meatpiHQ]

@romainreignier Please remove R20, it's marked in the picture below. You can desolder it or just use a tweezers to flick it off the PCB. I've tested on a fresh raspberry pi just now and this fix works.

[romainreignier]

@meatpiHQ I have removed R20 and the Linux cdc-acm driver now works directly! Thanks a lot @jamesturton A noticed should be issued to the users or at least in the README of this repo.

[meatpiHQ]

@romainreignier Done :)

https://github.com/meatpiHQ/meatpi_ollie_v2?tab=readme-ov-file#linux

[opticron]

Is there any downside to removing R20?

[meatpiHQ]

Is there any downside to removing R20?

No downside. On the latest batch that resistor is unpopulated.