Skip to content

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

Closed
@per1234

Description

@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:

// 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:

Related

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

Metadata

Metadata

Assignees

Labels

conclusion: resolvedIssue was resolvedos: windowsSpecific to Windows operating systemtopic: codeRelated to content of the project itselftype: imperfectionPerceived defect in any part of project

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions