USB Serial Adapter ( CH340 ) - uchcom / ucom driver not detecting the device
-
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 ucomreturns emptyi 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-L4909C17see 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 = 0x0001dmesg 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 ucomtold me so aswell:kldload: can't load ucom: module already loaded or in kernelas 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
-
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 usbus0And that is then available as /dev/cuaU0 or /dev/ttyU0. Where the upper case 'U' indicates it's USB connected.
Steve
-
@stephenw10
ugen0.2: <vendor 0x1a86 USB2.0-Ser> at usbus0thats all, basically the same as i found while scrolling through the full dmesg output
-
And I assume you see no such devices in /dev?
-
@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 -
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.
-
@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 -
Run:
echo 'boot_verbose="YES"' >> /boot/loader.conf.localThen reboot.
-
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 = 0x0001It doesn't create any
cuaorttydevices 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 theugen, 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.Yport. -
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/2441363It'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
-
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.
-
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
-
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.
