XON XOFF problems with CH340G on Arduio Uno clone

Greetings –

I’ve encountered a very odd problem with XON XOFF flow control when using $4 Ebay Arduino UNO clones that use the CH340G for the USB to serial converter.

I wonder of others have encountered this problem and have any suggestions on how to solve the problem.

I know that the Arduino provided serial functions (e.g, Serial.write(), Serial.read() ) do not do anything special with CTL-S (0x13) or CTL-Q (0x11) (XOFF and XON characters), they just pass them on through like they do normal printable ASCII characters. So I built my own Arduino code to provide incoming XON-XOFF flow control, to throttle back external devices (like a W10 PC) when it’s dumping ASCII plain text data to the Arduino over the serial port.

I know that my Arduino XON XOFF software is working for two reasons (1) it functions correctly when I hardware hack on the UNO board to electrically disconnect the CH340G and replace it with either a Silicon Labs CP2102 or a FTDI USB-Serial adapter, and (2) all signal timing looks correct as displayed by a logic analyzer connected to the Arduio serial input and output ports.

I also know, via separate Arduino test code that I wrote, that the Arduino UNO, with the CH340G, can send and receive all 256 possible 8 bit values via the UART, values from 0x00 through 0xff inclusive, including 0x11 and 0x13, without any problems. So, in at least some cases, the CH340G can pass 0x11 and 0x13 in both directions.

And yet, when using my XON XOFF Arduino code that worked correctly with the CP2102 and FTDI, when I reconnect the CH340G, the XON XOFF no longer throttles back the upstream sending device (usually a W10 computer). It’s as though the upstream sending device never gets the uploaded CTL-S (0x13) from the Arduino. I think that’s because the 0x13 character from the Arduino to the W10 PC is being impaired by the CH340G in certain cases (like when a lot of data is moving in the download direction), but I don’t know that for certain.

I’m running the latest Windows driver for CH340G (ver 3.5.2019.1, Jan 30, 2019)

Have others encountered this XON XOFF problem with the CH340G? Have others found effective workarounds or solutions (other than simply replacing the CH340G with a CP2102 or FTDI)?

I welcome all comments and suggestions.

Thank you.

I guess that's a problem of the driver on the PC side. I cannot tell you anything about the Windows driver (I don't use that OS) but as the Linux driver is based on a reverse engineering of the Windows driver (afaik) I guess the findings apply too. The driver implements only basic UART functionality, for example parity or multiple stop bits are not supported (simply ignored in the driver).

If XON/XOFF is handled by the driver on Windows (on Linux this is done on the TTY layer) chances are that the CH340 driver simply does not handle it.

Thank you for your comments. That makes sense. The system behaves as though the Windows Driver for the CH340G (the driver created by the vendor of the CH340G IC) simply ignores XON XOFF flow control.

Is XON/XOFF a driver level or a program level thing?
I always assumed it was a program level thing as how would the driver know when to issue an XON/XOFF.

Riva:
Is XON/XOFF a driver level or a program level thing?
I always assumed it was a program level thing as how would the driver know when to issue an XON/XOFF.

The flow control setting is supposed to be passed to the CH340G chip via the device driver.
Under windows it's
Control panel > Device Manager > Serial Ports > Port Settings > Flow Control > None, xon/xoff, hardware