USB Serial Adapter ( CH340 ) - uchcom / ucom driver not detecting the device

Psych0D0g

Hello everyone, i am currently setting up pfsense ( 2.7.0-RELEASE (amd64) ) on a Lenovo ThinkCenter m720q for the first time (so far I've been using openwrt in my home lab)
i am struggling to get my usb->serial adapter recognized within pfsense to then setup communications to my UPS, the physical USB hardware itself is detected by the kernel but the ucom module responsible for the vendor:product ID is not detecting it.
dmesg | grep ucom returns empty

i checked the module source on freebsd and it should correspond to this line in the driver:
https://github.com/freebsd/freebsd-src/blob/stable/14/sys/dev/usb/serial/uchcom.c#L327C33-L327C33
and
the following line in the usbdevs definitions beholds the product ID (0x7523) of my adapter:
https://github.com/freebsd/freebsd-src/blob/stable/14/sys/dev/usb/usbdevs#L4909C17-L4909C17

see the output of usbconfig -v list:

ugen0.2: <vendor 0x1a86 USB2.0-Ser> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x00ff  <Vendor specific>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0008 
  idVendor = 0x1a86 
  idProduct = 0x7523 
  bcdDevice = 0x0254 
  iManufacturer = 0x0000  <no string>
  iProduct = 0x0002  <USB2.0-Ser!>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

dmesg output only shows the physical hardware aswell, no messages from ucom kernel module / stack.

ive read here on the forums that this driver is included in the kernel and not available or needed as a module and behold a
kldload ucom told me so aswell:

kldload: can't load ucom: module already loaded or in kernel

as my knowledge on freebsd is fairly limited, i have reached the end of my own debugging capabilities here.
Am i missing something entirely obvious to the average freebsd user?
can anyone steer me in the right direction?

Greetings and thank you for your time

stephenw10

I would boot with it unplugged. Then plug it in and see what shows up in the system log and/or on the console.
For example plugging in a device here shows:

Sep 1 13:58:20 	kernel 		ugen0.2: <FTDI FT232R USB UART> at usbus0
Sep 1 13:58:20 	kernel 		uftdi0 on uhub0
Sep 1 13:58:20 	kernel 		uftdi0: <FT232R USB UART> on usbus0

And that is then available as /dev/cuaU0 or /dev/ttyU0. Where the upper case 'U' indicates it's USB connected.

Steve

Psych0D0g

@stephenw10
ugen0.2: <vendor 0x1a86 USB2.0-Ser> at usbus0

thats all, basically the same as i found while scrolling through the full dmesg output

stephenw10

And I assume you see no such devices in /dev?

Psych0D0g

@stephenw10 nothing that would resemble a corresponding entry that would fit imho

[2.7.0-RELEASE][root@pfSense.lan.crystalnet.org]/root: ls /dev/
acpi                  atkbd0                cpuctl0               devctl                full                  kbd1                  mixer0                nvd0                  pts                   stdin                 ttyv4                 ufssuspend            xpt0
ada0                  audit                 cpuctl1               devctl2               geom.ctl              kbdmux0               mixer1                nvme0                 random                stdout                ttyv5                 ugen0.1               zero
ada0p1                auditpipe             cpuctl2               devstat               gpt                   klog                  mixer2                nvme0ns1              reroot                sysmouse              ttyv6                 ugen0.2               zfs
ada0p2                bnxt_mgmt             cpuctl3               dumpdev               hpet0                 kmem                  mlx5ctl               pass0                 sequencer0            tcp_log               ttyv7                 ugen0.3
ada0p3                bpf                   cpuctl4               efi                   input                 led                   music0                pass1                 ses0                  ttyv0                 ttyv8                 uinput
ada0p4                bpf0                  cpuctl5               enc@n3061686369656d30 io                    mdctl                 netdump               pci                   sndstat               ttyv1                 ttyv9                 urandom
apm                   console               crypto                fd                    iov                   mem                   netmap                pf                    speaker               ttyv2                 ttyva                 usb
apmctl                consolectl            ctty                  fido                  kbd0                  midistat              null                  pfil                  stderr                ttyv3                 ttyvb                 usbctl

stephenw10

Hmm, you have no com ports at all, not even the standard UARTs.

I expect to see some output from connecting that device even if it fails to attach. You might try booting in verbose mode to see more.

Psych0D0g

@stephenw10 is there a way to reboot into verbose without having to manually select it during boot?
currently its headless and installed in my rack, if i could spare myself getting a monitor over there or ripping out the system that would be a huge plus :D

stephenw10

Run:

echo 'boot_verbose="YES"' >> /boot/loader.conf.local

Then reboot.

jimp

While it's not connected to a UPS I have a few CH340 usb serial devices around and as far as I can see they don't appear to be supported on FreeBSD yet.

Mine looks identical to yours as well:

ugen1.3: <vendor 0x1a86 USB Serial> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x00ff  <Vendor specific>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0008 
  idVendor = 0x1a86 
  idProduct = 0x7523 
  bcdDevice = 0x0264 
  iManufacturer = 0x0000  <no string>
  iProduct = 0x0002  <USB Serial>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

It doesn't create any cua or tty devices in /dev/ after plugging it in either.

That said, that doesn't necessarily stop a UPS monitor program from working with it. I have a couple APC UPS devices that act similarly, no serial devices in /dev, just the ugen, and yet they still work fine with APCUPSD and NUT with the right settings for the UPS.

In those cases you just have the UPS monitor load its own USB device drivers and then point it at the right ugenX.Y port.

bingo600

My suggestion would be to get a "Real" FTDI adapter (aka .. no fake chip).

I can recommend the US232R-100-BULK.
https://ftdichip.com/products/us232r-100-bulk/
https://www.digikey.com/en/products/detail/ftdi-future-technology-devices-international-ltd/US232R-100-BULK/2441363

It's pricey compared to a CH340, but they "just work" , and have a unique serial number coded.

I have experienced a bit of a device name "lottery", if using multiple devices connected, that has no (or same) serial number.
The unique serial number enables most drivers to "attach" the device with the same device name on consecutive boots.

If you go for a "Chinese" FTDI, my experience is that they'll work on linux.
But don't connect it to a windows machine, FTDI might deliberately kill the clone(s) wia it's windows driver (they set the clone vid:pid to zero) .

I have primarily switched to "Chinese" Silabs CP2102/CP2104 adapters if i want something that just works out of the box.
But i don't know if they're supported on pfSense (FreeBSD) , and i'm in the summerhouse right now.

Another gotcha with some of the CH340's in the TTL output version , is that they output 5v on the IO pins even if the 3v3 jumper is selected.
Some "genious" connected Vio to Vusb on the PCB , instead of to the voltage jumper switch.

/Bingo

jimp

If it's a device you are using deliberately, then yeah a higher quality adapter is better. If that is the chip built into the device they may not have a choice.

I use the little cheap CH340 devices for talking SPI and similar to program attiny chips in certain use cases. I've also used them successfully for serial consoles on certain SBCs like orange Pi devices. Those are things a more fully-featured serial adapter can't do just because they are fundamentally different in design.

bingo600

I totally agree wrt. the CH340 being nice, especially for the price.
And i use them too for embedded stuff. Just be aware that some of them will have 5v IO even if set to 3v3.

For highspeed bitbanging i use FT2232H, the MPSSE engine is FAST.

But for an embedded reliable 3v3 "plain" serial adapter i go for the Silabs CP2102/04 , not that pricey too.
And OS support is excellent ... But on linux the CH340 support is fine too.

For an RS-232 (V.24) 9-pin Serial-->USB adapter, i tend to use a "Real FTDI" , and the one mentioned above is my favourite , but i agree i don't buy them in 5's or 10's , like the CH340

/Bingo

Psych0D0g

so yeah, problem with the ftdi etc adapters are, as they are not "as cheaply made" as the CH340's, the plugs are not easily disassembled, my serial side is just 2 plasic halves that i was able to easily disassemble to resolder some pins to diffrent ones (to make it compatible with the APC pinout without the need for any special adapter or cable, basically adding a USB port to my apc by directly plugging the serial adapter into it)
thats not possible to archive using higher quality adapters where the plug is sealed in some kind of rubber all around.