7-bit Even Parity (7E1) Data Corruption on Waveshare SKU 28214

[maovidal]

Description:

I am experiencing data corruption when using the Waveshare SKU 28214 (ch348) with a Modbus ASCII RS485 device. The communication requires 115200 baud, 7 data bits, Even parity, and 1 stop bit (7E1).

While a generic USB-RS485 adapter works perfectly with these exact settings, the Waveshare device using the ch9344 driver results in corrupted exchanges. It appears to me the driver is not correctly handling the 7-bit parity bit or is failing to mask the 8th bit, leading the Modbus slave to misinterpret the frames.

On the Linux device with Kernel 6.12, the Waveshare is correctly identified by the driver:

Bus 001 Device 007: ID 1a86:55d9 wch.cn USB2.0 To Multi Serial Ports

Steps to Reproduce:

1. Connect a Waveshare SKU 28214 (Or any ch348 based device?) to a Modbus ASCII slave.
2. Configure the port for 7E1 (115200 baud).
3. Attempt a standard Modbus read (Function Code 04).

Observed Behavior:
The exchange is corrupted. The slave receives or returns invalid ASCII patterns such as:

:A
 D        R4LC
:0104344A43000E0003000500200000000101250000000000000000000F00070004000400020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCD

In a working exchange with a generic adapter, the pattern is clean Modbus ASCII:

:01040000001AE1
:0104344A43000E0003000500200000000101240000000000004000000F00070004000400040000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8C

Port Configuration (stty -a):

Linux reports this when the Modbus application has configured the port:

speed 115200 baud; line = 0;
parenb -parodd -cmspar cs7 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff

Requested Action:

Please verify the parity calculation logic in ch9344.c, specifically for CS7 (7-bit) modes. It seems the 8th bit (parity) is not being correctly managed or positioned within the byte frame, which is critical for Modbus ASCII compliance.

[maovidal]

Technical Diagnosis and Solution for CH348L Modbus ASCII (7-bit) Corruption and RS485 Timeouts

We have successfully diagnosed and resolved the Modbus ASCII (7E1) issues on the CH348L (ID 1a86:55d9). Our testing involved a dual-capture methodology using the ch9344 driver vs. a hardware sniffer on /dev/ttyUSB0. The sniffer showed perfect ASCII frames while the driver reported bit-shifted/corrupted bytes.

1. RS485 Auto-Directionality Fix
   In ch9344_set_control, the register R_C4 was being set to 0x51. For the CH348L, Bit 7 (0x80) is mandatory for "Automatic RS485 Direction Control". Without it, the chip remains in TX mode and fails to receive the slave response.
   Solution: Change control = 0x51 to 0xd1 for the CH348 series.

2. Structural 7-bit Data Corruption
   We found that the chip's native 7-bit hardware mode (7E1/7O1) causes bit-alignment issues in the received URB data. Even with bitmasking, bytes like \n (0x0A) were received as 0x8A or shifted values.

3. Proposed Fix: "8N1 Hardware Transparent Hack"
   To ensure stable communication, we implemented a software-based bit-handling approach:

• Hardware Config: Force the hardware into 8-bit No Parity (8N1) mode even when 7-bit Even/Odd Parity is requested. This treats the serial frame as a transparent 8-bit stream (7 bits data + 1 bit parity).
• Software Masking: Apply a bitmask (&= 0x7f) to each received byte in ch9344_process_read_urb before pushing to the TTY flip buffer.
• Outcome: This bypasses the chip's internal 7-bit sampling issues and delivers clean ASCII data to the application (e.g., Python's pymodbus).

Key implementation logic:

• In ch9344_tty_set_termios: If CSIZE is CS7, override newline.bDataBits = 8 and newline.bParityType = 0 for the hardware command.
• In ch9344_process_read_urb: Ensure buffer[k] &= 0x7f is applied to all incoming data if the tty is in 7-bit mode.

This solution has been verified as stable at 115200 Baud with no timeouts or corruption.

[WCHSoftGroup]

Hi, the problem you are experiencing is due to the use of an older version of the chip. The chip you are using currently only supports 8 data bits.

[WCHSoftGroup]

You can resolve the above issue by purchasing a new version of the chip. The surface markings on the new version chip begin with 31452*.

[maovidal]

Thanks. I'm an end-user fixing a Waveshare device, not looking to buy ICs. Waveshare support hasn't provided a solution yet.

I managed a temporary workaround for this serial port limitation by patching the kernel module. I've opened a Pull Request here #49 so you can review the changes.

Since a software fix is clearly possible, does WCH plan to officially update the driver to resolve this?