avrdude serialupdi issues under FreeBSD 14.0 with CH340 USB to TTL converter

[mcuee]

Under both physical machine and Proxmox VM, I have the same issue.

The following is under a physical machine (Intel J4125 mini PC).

mcuee@freebsd14:~ $ uname -a
FreeBSD freebsd14 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

mcuee@freebsd14:~ $ ldd /usr/local/bin/avrdude
/usr/local/bin/avrdude:
        libm.so.5 => /lib/libm.so.5 (0x2fd5631c0000)
        libelf.so.0 => /usr/local/lib/libelf.so.0 (0x2fd564047000)
        libusb.so.3 => /usr/lib/libusb.so.3 (0x2fd5641ff000)
        libhidapi.so.0 => /usr/local/lib/libhidapi.so.0 (0x2fd565581000)
        libftdi.so.1 => /usr/local/lib/libftdi.so.1 (0x2fd564bac000)
        libftdi1.so.2 => /usr/local/lib/libftdi1.so.2 (0x2fd5662e9000)
        libreadline.so.8 => /usr/local/lib/libreadline.so.8 (0x2fd5667bd000)
        libserialport.so.0 => /usr/local/lib/libserialport.so.0 (0x2fd56763c000)
        libncursesw.so.9 => /lib/libncursesw.so.9 (0x2fd56789f000)
        libc.so.7 => /lib/libc.so.7 (0x2fd5686a0000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2fd56a849000)
        libthr.so.3 => /lib/libthr.so.3 (0x2fd5691df000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x2fd569f4d000)
        libtinfow.so.9 => /lib/libtinfow.so.9 (0x2fd56bc0e000)
        [vdso] (0x2fd5625c9000)

mcuee@freebsd14:~ $ avrdude -c serialupdi -P /dev/cuaU0 -p avr64dd32
avrdude OS error: tcsetattr() failed
avrdude OS error: cannot set attributes for port /dev/cuaU0: Input/output error
avrdude error: unable to open port /dev/cuaU0 for programmer serialupdi
Possible candidate serial ports are:
  -P /dev/cuaU0 (via ch340 serial adapter)
  -P /dev/cuaU1 (via ch340 serial adapter)
Note that above ports might not be connected to a target board or an AVR programmer.
Also note there may be other direct serial ports not listed above.

avrdude done.  Thank you.

-c urclock works with CH340 based Uno clone using ATmega328PB.

mcuee@freebsd14:~ $ avrdude -c urclock -P /dev/cuaU1 -p m328pb
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)

avrdude done.  Thank you.

[mcuee]

Building without libserialport does not help.

mcuee@freebsd14:~/build/avrdude $ ./build.sh -f "-D HAVE_LIBSERIALPORT:BOOL=OFF"
...
mcuee@freebsd14:~/build/avrdude $ ./build_freebsd/src/avrdude -c serialupdi -P /dev/cuaU1 -p avr64dd32
avrdude OS error: tcsetattr() failed
avrdude OS error: cannot set attributes for port /dev/cuaU1: Input/output error
avrdude error: unable to open port /dev/cuaU1 for programmer serialupdi
avrdude error: avrdude built without libserialport support; please compile again with libserialport installed

avrdude done.  Thank you.

[mcuee]

@dl8dtl

Just wondering if you can help to see if you are able to reproduce the issue or not. Thanks.

I have only done some simple tests using avrdude-test-script under FreeBSD 14.0.

• avrdude 7.3 release discussion #1473 (comment)

FreeBSD 14 x86_64 virtual machine or Intel J4125 Mini PC physical machine

• build.sh
• dryrun
• usbasp
• urclock
• serialupdi --> seems to have problems

[mcuee]

Very old reports of similar issue is for Solaris 10/11i back in 2008. So it is probably not relevant.

• [bug #22206] avrdude: ser_setspeed(): tcsetattr() failed #123

[mcuee]

No issues under NetBSD 9.3.

-bash-5.2$ uname -a
NetBSD localhost 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

-bash-5.2$ avrdude -c serialupdi -P /dev/ttyU0 -p avr64dd32
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961a (probably avr64dd32)

avrdude done.  Thank you.

-bash-5.2$ ./test-avrdude -p "-c serialupdi -P /dev/ttyU0 -p avr64dd32"
Testing avrdude version 7.2-20240122 (2f89aece)
Prepare "-c serialupdi -P /dev/ttyU0 -p avr64dd32" and press 'enter' or 'space' to continue. Press any other key to skip
✅   0.000 s: set, clear and read eesave fuse bit
✅  19.062 s: the_quick_brown_fox_65536B.hex flash -U write/verify
✅  10.758 s: the_quick_brown_fox_256B.hex eeprom -U write/verify
✅  19.072 s: lorem_ipsum_65536B.srec flash -U write/verify
✅  10.778 s: lorem_ipsum_256B.srec eeprom -U write/verify
✅  10.798 s: 0xff_256B.hex eeprom -U write/verify
✅  10.798 s: the_quick_brown_fox_65536B.hex:a flash -T write/verify
✅  10.798 s: the_quick_brown_fox_256B.hex:a eeprom -T write/verify
✅  10.798 s: lorem_ipsum_65536B.srec flash -T write/verify
✅  10.798 s: lorem_ipsum_256B.srec eeprom -T write/verify
✅  10.798 s: cola-vending-machine.raw flash -T/-U write/verify
✅   5.845 s: holes_pack_my_box_65536B.hex:a flash -U write
✅   5.845 s: holes_the_five_boxing_wizards_65536B.hex flash -T write
✅   3.744 s: holes_pack_my_box_256B.hex:a eeprom -U write
✅   3.744 s: holes_the_five_boxing_wizards_256B.hex eeprom -T write
✅   1.433 s: random_data_32B.bin usersig -T/-U write/read

[mcuee]

No issues under OpenBSD 7.4 either (Intel N4500 mini PC, physical machine).

openbsd74$ uname -a
OpenBSD openbsd74.my.domain 7.4 GENERIC.MP#1397 amd64

openbsd74$ ./test-avrdude -p "-c serialupdi -P /dev/ttyU0 -p avr64dd32"
Testing avrdude version 7.2-20240122 (2f89aece)
Prepare "-c serialupdi -P /dev/ttyU0 -p avr64dd32" and press 'enter' or 'space' to continue. Press any other key to skip
✅   0.000 s: set, clear and read eesave fuse bit
✅  21.795 s: the_quick_brown_fox_65536B.hex flash -U write/verify
✅  12.634 s: the_quick_brown_fox_256B.hex eeprom -U write/verify
✅  21.785 s: lorem_ipsum_65536B.srec flash -U write/verify
✅  12.634 s: lorem_ipsum_256B.srec eeprom -U write/verify
✅  12.654 s: 0xff_256B.hex eeprom -U write/verify
✅  12.654 s: the_quick_brown_fox_65536B.hex:a flash -T write/verify
✅  12.654 s: the_quick_brown_fox_256B.hex:a eeprom -T write/verify
✅  12.654 s: lorem_ipsum_65536B.srec flash -T write/verify
✅  12.654 s: lorem_ipsum_256B.srec eeprom -T write/verify
✅  12.654 s: cola-vending-machine.raw flash -T/-U write/verify
✅   7.645 s: holes_pack_my_box_65536B.hex:a flash -U write
✅   7.645 s: holes_the_five_boxing_wizards_65536B.hex flash -T write
✅   5.594 s: holes_pack_my_box_256B.hex:a eeprom -U write
✅   5.594 s: holes_the_five_boxing_wizards_256B.hex eeprom -T write
✅   3.294 s: random_data_32B.bin usersig -T/-U write/read

[askn37]

Does the problem occur with USB serial adapters other than the CH340 series?

If you can use another serial adapter, the problem is most likely with the CH340 series driver. In some cases, reducing the speed may improve the situation.

If other serial adapters also do not work, there may be an issue with the USB passthrough feature between the physical PC and the guest operating system.

[mcuee]

@askn37

The latest tests are done with physical machine and not virtual machine.

I will see if I can test with another USB to Serial adapter.

CH340 driver support should be quite mature for FreeBSD 14.0 (latest Release version). And FreeBSD is supposed to have better driver support than OpenBSD/NetBSD.

[dbuchwald]

If I can chip in: the only difference between serialupdi and urclock is the pflag field content.

• serialupdi uses SERIAL_8E2
• urclock uses SERIAL_8N1

These flags are defined in here: https://github.com/avrdudes/avrdude/blob/main/src/libavrdude.h#L797-L799

Then, in turn, these are translated to OS-specific flags here: https://github.com/avrdudes/avrdude/blob/main/src/libavrdude.h#L797-L799

Difference between the two modes is SERIAL_NO_CSTOPB/SERIAL_CSTOPB and SERIAL_NO_PARITY/SERIAL_PARENB, which translates to:

  if (cflags & SERIAL_CSTOPB) {
    termios.c_cflag |= CSTOPB;
  } else {
    termios.c_cflag &= ~CSTOPB;
  }

and

  if (cflags & (SERIAL_PARENB | SERIAL_PARODD)) {
    termios.c_cflag |= PARENB;
  } else {
    termios.c_cflag &= ~PARENB;
  }

  if (cflags & SERIAL_PARODD) {
    termios.c_cflag |= PARODD;
  } else {
    termios.c_cflag &= ~PARODD;
  }

Maybe one of these is not recognized correctly by FreeBSD implementation of serial interface?

[mcuee]

I modified the libserialport example and it seems to me 7E2 does not work for CH340 based USB-TTL converter and 8N1 works.

Same with the build-in example port_config.

I carry out the tests with another virtual machine running FreeBSD 13.2 Release this time. It was the same when I tested with the physical machine running FreeBSD 14.0 Release.

mcuee@freebsd132vmn100:~/build/libserialport/examples $ cc -I /usr/local/include test1.c  -L /usr/local/lib -l serialport -lusb -o test1
mcuee@freebsd132vmn100:~/build/libserialport/examples $ ./test1 /dev/cuaU0
Looking for port /dev/cuaU0.
Port name: /dev/cuaU0
Description: USB Serial
Opening port.
Setting port to 115200 8N1, no flow control.
Baudrate: 115200, data bits: 8, parity: None, stop bits: 1

mcuee@freebsd132vmn100:~/build/libserialport/examples $ ./test /dev/cuaU0
Looking for port /dev/cuaU0.
Port name: /dev/cuaU0
Description: USB Serial
Opening port.
Setting port to 115200 7E2, no flow control.
Error: Failed: Input/output error
Abort trap (core dumped)

mcuee@freebsd132vmn100:~/build/libserialport/examples $ ./port_config /dev/cuaU0
Looking for port /dev/cuaU0.
Port name: /dev/cuaU0
Description: USB Serial
Opening port.
Setting port to 115200 8N1, no flow control.
Baudrate: 115200, data bits: 8, parity: None, stop bits: 1
Creating new config for 9600 7E2, XON/XOFF flow control.
Applying new configuration.
Error: Failed: Input/output error
Abort trap (core dumped)

[mcuee]

No issues with an FTDI USB to Serial Converter (this is not a USB to TTL converter so I can not use it).

mcuee@freebsd132vmn100:~/build/libserialport/examples $ ./port_config /dev/cuaU0
Looking for port /dev/cuaU0.
Port name: /dev/cuaU0
Description: (null)
Opening port.
Setting port to 115200 8N1, no flow control.
Baudrate: 115200, data bits: 8, parity: None, stop bits: 1
Creating new config for 9600 7E2, XON/XOFF flow control.
Applying new configuration.
Setting port back to previous config.

mcuee@freebsd132vmn100:~/build/libserialport/examples $ ./test1 /dev/cuaU0
Looking for port /dev/cuaU0.
Port name: /dev/cuaU0
Description: (null)
Opening port.
Setting port to 115200 8N1, no flow control.
Baudrate: 115200, data bits: 8, parity: None, stop bits: 1

mcuee@freebsd132vmn100:~/build/libserialport/examples $ ./test /dev/cuaU0
Looking for port /dev/cuaU0.
Port name: /dev/cuaU0
Description: (null)
Opening port.
Setting port to 115200 7E2, no flow control.
Baudrate: 115200, data bits: 7, parity: Even, stop bits: 2

[mcuee]

Okay, it seems to me FreeBSD really does not like CH340.
https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c

#include <sys/cdefs.h>
/*
 * Driver for WinChipHead CH341/340, the worst USB-serial chip in the
 * world.
 */

@dl8dtl

Please help to check if you can set 7E2 if you happen to have a CH340 based USB to Serial converter. Thanks.

[mcuee]

It seems to me only serialupdi uses 7E2.
jtag2updi does not seem to have issues. The following test is with Nano 4808 (CH340 + a USB 8051 MCU, custom FW for jtag2updi).

mcuee@freebsd132vmn100:~/build/avrdude-test-script $ ./test-avrdude -p "-c jtag2updi -P /dev/cuaU0 -p m4808"
Testing avrdude version 7.2-20240122 (2f89aece)
Prepare "-c jtag2updi -P /dev/cuaU0 -p m4808" and press 'enter' or 'space' to continue. Press any other key to skip
✅   0.000 s: set, clear and read eesave fuse bit
✅  23.432 s: the_quick_brown_fox_49152B.hex flash -U write/verify
✅   1.352 s: the_quick_brown_fox_256B.hex eeprom -U write/verify
✅  23.438 s: lorem_ipsum_49152B.srec flash -U write/verify
✅   1.352 s: lorem_ipsum_256B.srec eeprom -U write/verify
✅   1.502 s: 0xff_256B.hex eeprom -U write/verify
✅   1.502 s: the_quick_brown_fox_49152B.hex:a flash -T write/verify
✅   1.502 s: the_quick_brown_fox_256B.hex:a eeprom -T write/verify
✅   1.502 s: lorem_ipsum_49152B.srec flash -T write/verify
✅   1.502 s: lorem_ipsum_256B.srec eeprom -T write/verify
✅   1.502 s: cola-vending-machine.raw flash -T/-U write/verify
✅   6.885 s: holes_pack_my_box_49152B.hex:a flash -U write
✅   6.885 s: holes_the_five_boxing_wizards_49152B.hex flash -T write
✅   1.312 s: holes_pack_my_box_256B.hex:a eeprom -U write
✅   1.312 s: holes_the_five_boxing_wizards_256B.hex eeprom -T write
✅   1.242 s: random_data_64B.bin usersig -T/-U write/read

[mcuee]

Anyway, I do not think this is an avrdude serialupdi issue. I will close this and transfer to a discussion.

[mcuee]

This issue is with FreeBSD CH340 driver and not avrdude.

[mcuee]

FreeBSD ch340 driver does not seem to support parity bits and stop bits settings.
https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c

static int
uchcom_pre_param(struct ucom_softc *ucom, struct termios *t)
{
	struct uchcom_divider dv;

	switch (t->c_cflag & CSIZE) {
	case CS8:
		break;
	default:
		return (EIO);
	}
	if ((t->c_cflag & CSTOPB) != 0)
		return (EIO);
	if ((t->c_cflag & PARENB) != 0)
		return (EIO);

	if (uchcom_calc_divider_settings(&dv, t->c_ospeed)) {
		return (EIO);
	}
	return (0);			/* success */
}

OpenBSD -- similar to NetBSD but with will error out with a certain revision of CH340
#define UCHCOM_REV_CH340 0x0250

https://github.com/openbsd/src/blob/master/sys/dev/usb/uchcom.c

int
uchcom_set_line_control(struct uchcom_softc *sc, tcflag_t cflag)
{
	usbd_status err;
	uint8_t lcr = 0, lcr2 = 0;

	if (sc->sc_release == UCHCOM_REV_CH340) {
		/*
		 * XXX: it is difficult to handle the line control
		 * appropriately on CH340:
		 *   work as chip default - CS8, no parity, !CSTOPB
		 *   other modes are not supported.
		 */
		switch (ISSET(cflag, CSIZE)) {
		case CS5:
		case CS6:
		case CS7:
			return EINVAL;
		case CS8:
			break;
		}
		if (ISSET(cflag, PARENB) || ISSET(cflag, CSTOPB))
			return EINVAL;
		return 0;
	}

	err = uchcom_read_reg(sc, UCHCOM_REG_LCR, &lcr,
	    UCHCOM_REG_LCR2, &lcr2);
	if (err) {
		printf("%s: cannot get LCR: %s\n",
		    sc->sc_dev.dv_xname, usbd_errstr(err));
		return EIO;
	}

	lcr = UCHCOM_LCR_RXE | UCHCOM_LCR_TXE;

	switch (ISSET(cflag, CSIZE)) {
	case CS5:
		lcr |= UCHCOM_LCR_CS5;
		break;
	case CS6:
		lcr |= UCHCOM_LCR_CS6;
		break;
	case CS7:
		lcr |= UCHCOM_LCR_CS7;
		break;
	case CS8:
		lcr |= UCHCOM_LCR_CS8;
		break;
	}

	if (ISSET(cflag, PARENB)) {
		lcr |= UCHCOM_LCR_PARENB;
		if (!ISSET(cflag, PARODD))
			lcr |= UCHCOM_LCR_PAREVEN;
	}

	if (ISSET(cflag, CSTOPB)) {
		lcr |= UCHCOM_LCR_STOPB;
	}

	err = uchcom_write_reg(sc, UCHCOM_REG_LCR, lcr, UCHCOM_REG_LCR2, lcr2);
	if (err) {
		printf("%s: cannot set LCR: %s\n",
		    sc->sc_dev.dv_xname, usbd_errstr(err));
		return EIO;
	}

	return 0;
}

NetBSD -- seems to be most updated
https://github.com/NetBSD/src/blob/trunk/sys/dev/usb/uchcom.c

static int
set_line_control(struct uchcom_softc *sc, tcflag_t cflag)
{
	usbd_status err;
	uint8_t lcr = 0, lcr2 = 0;

	err = read_reg(sc, UCHCOM_REG_LCR, &lcr, UCHCOM_REG_LCR2, &lcr2);
	if (err) {
		device_printf(sc->sc_dev, "cannot get LCR: %s\n",
		    usbd_errstr(err));
		return EIO;
	}

	lcr = UCHCOM_LCR_RXE | UCHCOM_LCR_TXE;

	switch (ISSET(cflag, CSIZE)) {
	case CS5:
		lcr |= UCHCOM_LCR_CS5;
		break;
	case CS6:
		lcr |= UCHCOM_LCR_CS6;
		break;
	case CS7:
		lcr |= UCHCOM_LCR_CS7;
		break;
	case CS8:
		lcr |= UCHCOM_LCR_CS8;
		break;
	}

	if (ISSET(cflag, PARENB)) {
		lcr |= UCHCOM_LCR_PARENB;
		if (!ISSET(cflag, PARODD))
			lcr |= UCHCOM_LCR_PAREVEN;
	}

	if (ISSET(cflag, CSTOPB)) {
		lcr |= UCHCOM_LCR_STOPB;
	}

	err = write_reg(sc, UCHCOM_REG_LCR, lcr, UCHCOM_REG_LCR2, lcr2);
	if (err) {
		device_printf(sc->sc_dev, "cannot set LCR: %s\n",
		    usbd_errstr(err));
		return EIO;
	}

	return 0;
}

[askn37]

FreeBSD ch340 driver does not seem to support parity bits and stop bits settings.

https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c#n61

/*
 * Driver for WinChipHead CH341/340, the worst USB-serial chip in the
 * world.
 */

https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c#n706

static void
uchcom_cfg_param(struct ucom_softc *ucom, struct termios *t)
{
	struct uchcom_softc *sc = ucom->sc_parent;

	uchcom_get_version(sc, NULL);
	uchcom_ctrl_write(sc, UCHCOM_REQ_RESET, 0, 0);
	uchcom_set_baudrate(sc, t->c_ospeed);
	if (sc->sc_version < UCHCOM_VER_30) {
		uchcom_read_reg(sc, UCHCOM_REG_LCR1, NULL,
		    UCHCOM_REG_LCR2, NULL);
		uchcom_write_reg(sc, UCHCOM_REG_LCR1, 0x50,
		    UCHCOM_REG_LCR2, 0x00);
	} else {
		/*
		 * Set up line control:
		 * - enable transmit and receive
		 * - set 8n1 mode
		 * To do: support other sizes, parity, stop bits.
		 */
		uchcom_write_reg(sc,
		    UCHCOM_REG_LCR1,
		    UCHCOM_LCR1_RX | UCHCOM_LCR1_TX | UCHCOM_LCR1_CS8,
		    UCHCOM_REG_LCR2, 0x00);
	}
	uchcom_update_status(sc);
	uchcom_ctrl_write(sc, UCHCOM_REQ_RESET, 0x501f, 0xd90a);
	uchcom_set_baudrate(sc, t->c_ospeed);
	uchcom_set_dtr_rts(sc);
	uchcom_update_status(sc);
}

It seems that no one has cleared the TODO for this driver manager so far.

[mcuee]

@cederom

Just wondering if you can confirm this as well. Thanks.

[MCUdude]

As for now I have two chips marked CH343G and only one of them somehow works ;-)

@cederom can you share the CH343 USB VID/PID? If they are different than the ones CH340 has (most likely just PID), then we can add the serial chip to avrdude.conf, so you can use -c ch343 instead of -c [serial port name/path].

[cederom]

In fact I was very surprised in this case as I always consider FreeBSD USB stack to be better than OpenBSD/NetBSD.

Unfortunately my good friend and creator of the USB stack for FreeBSD @hselasky died last year in a car accident so things may change now as he was the brain behind that marvelous implementation :-( :-( :-(

[cederom]

@cederom can you share the CH343 USB VID/PID? If they are different than the ones CH340 has (most likely just PID), then we can add the serial chip to avrdude.conf, so you can use -c ch343 instead of -c [serial port name/path].

I have provided already the device desctiptor dump above. Also added the undetected CD343 on ESP32-S3-Pico board. I am finishing big project right now and hopefully in February I will have some time to play again :-) If you want some quick test please provide setup example (target MCU + dongle) and what should I do in order to perform a test :-)

[MCUdude]

I have provided already the device descriptor dump above

I have no idea how I could miss this, sorry!

If you want some quick test please provide setup example (target MCU + dongle) and what should I do in order to perform a test :-)

I've just created a PR (#1640) where I've added the CH343 to avrdude.conf. Would be great if you could test it! Just make sure you have libserialport installed, so you can use -c ch343 or -c ch343:[sernum].

Unfortunately my good friend and creator of the USB stack for FreeBSD @hselasky died last year in a car accident

That's really sad to hear 😞

EDIT: I read a bit more about @hselasky, and It's amazing to read what he was able to accomplish! What a huge loss for everyone around him 💔

[cederom]

Yes HPS was a genius and amazing person. My hero! <3

CH343 conversation continued at #1640 :-)

[sdavejones]

Yes these chips are problematic there are lots of fakes with lots of surprises I have used them in one project and them trashed them away in favor CP2101 and FTDI :D But seeing OpenBSD and NetBSD works fine we need to fix the FreeBSD drivers too :-)

Quick search problems for CH340:

* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265533

* https://forums.freebsd.org/threads/uchcom-ch340-adapter-configuration-fails.78853/

Also I have new two ESP32-S3 devkits with CH343 chip and its not even recognized on FreeBSD:

* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272803

usb_alloc_device: set address 8 failed (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
ugen0.8: <Unknown > at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
usb_alloc_device: set address 8 failed (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)

I have another USB-to-UART board with H343G (marked as WaveShare 21442) and it seems to work. Not sure if this is the same chip if the marking is the same??? :D

Are you sure that WaveShare 21442 works? According to your usbconfig, the PID is 0x55d3, it doesn't support for uchcom(4):
https://cgit.freebsd.org/src/tree/sys/dev/usb/usbdevs#n4909

* https://www.waveshare.com/ch343-usb-uart-board.htm

% usbconfig -d 0.7 dump_device_desc
ugen0.7: <vendor 0x1a86 USB Single Serial> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (134mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0110
  bDeviceClass = 0x0002  <Communication device>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x1a86
  idProduct = 0x55d3
  bcdDevice = 0x0443
  iManufacturer = 0x0000  <no string>
  iProduct = 0x0002  <USB Single Serial>
  iSerialNumber = 0x0003  <5434023603>
  bNumConfigurations = 0x0001

I am still on 13.2-RELEASE. I can buy some more boards with CH340/* for testing. How can I help? :-)

[cederom]

@sdavejones: Are you sure that WaveShare 21442 works? According to your usbconfig, the PID is 0x55d3, it doesn't support for uchcom(4):
https://cgit.freebsd.org/src/tree/sys/dev/usb/usbdevs#n4909

as you can see I did usbconfig descriptor dump and it works for that WaveShare 21442 board. for esp32-s3-pico it does not work there are io errors.. maybe there is a firmware config or some specific quirks is required for that particular configuration to work (on windoze they require a dedicated driver). maybe these are different chips marked as CH343G who knows how that "modern technology" works :D

dmesg output:

ugen0.7: <vendor 0x1a86 USB Single Serial> at usbus0
umodem0 on uhub19
umodem0: <vendor 0x1a86 USB Single Serial, class 2/0, rev 1.10/4.43, addr 6> on usbus0
umodem0: data interface 1, has no CM over data, has no break

[mcuee]

Wiki updated.
https://github.com/avrdudes/avrdude/wiki/Known-limitations-of-avrdude