open command fails to connect to boards with CH340 USB chip on Windows

[per1234]

Describe the problem

The WCH CH340 USB to serial bridge chip is common on boards used by the Arduino community. The manufacturer of this chip recently released a new version of the Windows driver, which users are receiving via a Windows update.

🐛 The port is spuriously closed immediately after an open command under the following conditions:

• The port is produced by a CH340 USB chip.
• The user is using the Windows operating system
• The user has the latest CH340 driver version (3.9.2024.9) installed.

To reproduce

Equipment

• Any device that has a WCH CH340 USB chip.
• A Windows machine.

Steps

1. Connect the device to your computer with a USB cable.
2. Open Windows Device Manager.
3. Find the device under the "Ports (COM & LPT)" section of the Device Manager tree.
4. Right click on the device.
   A context menu will open.
5. Select "Properties" from the menu.
   The "USB-SERIAL CH340 (COM_n_) Properties" dialog will open.
6. Select the "Driver" tab in the dialog.
7. Verify that version 3.9.2024.9 is shown in the "Driver Version" field of the dialog.
8. Close the dialog and the Device Manager window.
9. Start Arduino Cloud Agent.
   An icon will appear in the Windows "notification area".
10. Click the Arduino Cloud Agent icon in the notification area.
    A menu will open.
11. Select "Open Debug Console" from the menu.
    The "Arduino Cloud Agent Debug Console" page will open in your browser.
12. Type open <port name> 9600 in the field at the bottom of the page.
    (where <port name> is the name of the serial port produced by the CH340 device)

🐛 The port is opened, but then immediately closed:

open COM17 9600

{
  "Cmd": "Open",
  "Desc": "Got register/open on port.",
  "Port": "COM17",
  "Baud": 9600,
  "BufferType": "default"
}

{
  "Cmd": "Close",
  "Desc": "Got unregister/close on port.",
  "Port": "COM17",
  "Baud": 9600
}

Shutting down writer on COM17

writerBuffered just got closed. make sure you make a new one. port:COM17

Expected behavior

Port remains open until disconnected or a close command is executed.

Cloud Agent version

d36d0e1

Operating system

• Windows

Operating system version

• Windows 11

Additional context

I found that the disconnection is caused by this code:

arduino-create-agent/serialport.go

Lines 158 to 165 in d36d0e1

	// Keep track of time difference between two consecutive read with n == 0 and err == nil
	// we get here if the port has been disconnected while open (cpu usage will jump to 100%)
	// let's close the port only if the events are extremely fast (<1ms)
	diff := time.Since(timeCheckOpen)
	if diff.Nanoseconds() < 1000000 {
	p.isClosingDueToError = true
	break
	}

Here is a derived minimal Go program that can be used to reproduce the fault:

package main

import (
	"log"
	"time"

	"go.bug.st/serial"
)

const portName string = "COM17"

func main() {
	mode := &serial.Mode{
		BaudRate: 9600,
	}
	port, err := serial.Open(portName, mode)
	if err != nil {
		log.Fatal(err)
	}

	timeCheckOpen := time.Now()
	buff := make([]byte, 100)
	for {
		n, err := port.Read(buff)
		if err != nil {
			log.Fatal(err)
			break
		}
		if n <= 0 {
			diff := time.Since(timeCheckOpen)
			if diff.Nanoseconds() < 1000000 {
				log.Println("Too soon since last empty read")
				break
			}
			timeCheckOpen = time.Now()
		}
	}
}

---

This problem causes the Arduino Cloud Editor Serial Monitor to fail to connect to the port, with the following error notification:

We can’t find the device, please make sure it is connected via serial port.
You can still see log history here, but data won’t be printed until new connection.

---

The fault does not occur after I install the older versions 3.8.2023.2 and 3.7.2022.1 of the CH340 driver.

---

The fault does not occur when using arduino-cli monitor.

---

The fault does not occur on my macOS and Linux machines.

---

The fault does not occur when using boards with other USB chips (FTDI FT232R, Silicon Labs CP2104, ATmega16U2 w/ Arduino firmware).

---

We are accustomed to seeing strange misbehavior associated with certain dodgy "CH340" chips when using the recent Windows driver versions (avrdudes/avrdude#1328). However, unlike those chips, the chips on the boards I used to reproduce the fault are labeled and from reputable manufacturers, and don't have any other problems with the latest drivers.

---

Originally reported at https://forum.arduino.cc/t/error-when-opening-serial-monitor-we-cant-find-the-device/1331419/1

Additional reports:

• https://forum.arduino.cc/t/error-when-opening-serial-monitor-we-cant-find-the-device/1331419/3
• https://forum.arduino.cc/t/serial-monitor-issue-esp32-from-cloud/1333079/1
• https://forum.arduino.cc/t/serial-monitor-issue-esp32-from-cloud/1333079/11
• https://forum.arduino.cc/t/error-when-opening-serial-monitor-we-cant-find-the-device/1331419/10

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the latest version
• My report contains all necessary details

[Reginald-Gillespie]

I was investigating the same issue - it makes sense that it was a CH340 driver update that broke it, was confused for a bit since the ACA hadn't had any updates pushed recently.

Since this impacts the classic Arduino Nano, I'm hoping it's a high-priority patch?

[per1234]

this impacts the classic Arduino Nano

I am not able to reproduce the fault using a classic Arduino Nano. From my tests, the fault is specific to the boards that have a CH340 USB chip. The official Arduino Nano uses the FTDI FT232 USB chip, not the CH340. However, the cheap Nano derivative boards do use the CH340 and I confirm that the fault affects those boards.

[Reginald-Gillespie]

Oh yes, I was looking at my off-brand boards. I assumed they were high enough quality to be exact clones, but I didn't check, mb.