uchcom / CH340 adapter configuration fails

Hello,

I am trying to connect 4 serial devices to a new install of FreeBSD 12.2 using CH340 USB to serial adapters. The boot display for all 4 show the same information (except for unit address of course).
Code:
Feb 11 23:41:34 new-sys kernel: ugen1.5: <vendor 0x1a86 USB2.0-Ser> at usbus1
Feb 11 23:41:34 new-sys kernel: uchcom0 on uhub4
Feb 11 23:41:34 new-sys kernel: uchcom0: <vendor 0x1a86 USB2.0-Ser, rev 1.10/2.54, addr 5> on usbus1
Feb 11 23:41:34 new-sys kernel: uchcom0: CH340 detected
They also show similar information for
Code:
usbconfig list
and
Code:
usbconfig -d ugen1.5 dump_all_config_desc

My problem is that only one works. The other 3 fail with a "no write access" error message.

The man page states:

DESCRIPTION​

The uchcom driver provides support for the WinChipHead CH341/CH340 USB-to-RS-232 Bridge chip.
The device is accessed through the ucom(4) driver which makes it behave like a tty(4).

HARDWARE​

The uchcom driver supports the following adapters:
  • HL USB-RS232
The adapter that works is labeled "HL-340". The other 3 are labeled "340". Does that indicate a difference in the adapter that can be addressed by a quirk? Or is there some other problem?

TIA for any help.

JJ
 
What are you trying to do? What causes that error?
I'm not sure the labelling makes a difference if they're all handled by ucom driver. That implies it recognises it.
Do you see all the devices in the device tree? Do they all have the same permissions?
 
I am trying to use NUT (from packages) to monitor APC UPSs. The error is displayed when starting apcsmart
Code:
[root@new-sys ~]# /usr/local/libexec/nut/apcsmart -a ups-1M
Network UPS Tools - APC Smart protocol driver 3.1 (2.7.4)
APC command table version 3.1
Communications with UPS lost: serial port write error: 1379(smartmode): Device not configured
unable to detect an APC Smart protocol UPS on port /dev/cuaU1
check the cabling, port name or model name and try again
Communications with UPS lost: serial port write error: 2051(upsdrv_cleanup): Device not configured
[root@new-sys ~]#
All UPSs work when connecting to the adapter labeled "HL-340". All UPSs fail with the above error when connecting with any of the 3 labeled "340".

All 4 adapters show the same in the device listing regardless of the order they are inserted and whether just one or all 4 are inserted. (Of course the device number assigned to the device depend on insertion order.)
Code:
[root@new-sys ~]# ls /dev/cua*
crw-rw----  1 uucp  dialer  0xa1 Feb 12 17:34 /dev/cuaU0
crw-rw----  1 uucp  dialer  0xa2 Feb 12 00:55 /dev/cuaU0.init
crw-rw----  1 uucp  dialer  0xa3 Feb 12 00:55 /dev/cuaU0.lock
crw-rw----  1 uucp  dialer  0x7d Feb 12 17:35 /dev/cuaU1
crw-rw----  1 uucp  dialer  0x7e Feb 12 17:35 /dev/cuaU1.init
crw-rw----  1 uucp  dialer  0x7f Feb 12 17:35 /dev/cuaU1.lock
crw-rw----  1 uucp  dialer  0xb5 Feb 12 00:55 /dev/cuaU2
crw-rw----  1 uucp  dialer  0xb6 Feb 12 00:55 /dev/cuaU2.init
crw-rw----  1 uucp  dialer  0xb7 Feb 12 00:55 /dev/cuaU2.lock
crw-rw----  1 uucp  dialer  0xbf Feb 12 00:55 /dev/cuaU3
crw-rw----  1 uucp  dialer  0xc0 Feb 12 00:55 /dev/cuaU3.init
crw-rw----  1 uucp  dialer  0xc1 Feb 12 00:55 /dev/cuaU3.lock
[root@new-sys ~]#

JJ
 
Oh, I remember these, the USB to serial adapters out of China that used to blue-screen windows 7 more often than not.
They seem to be a bit of a lottery as to whether they work or not.

Can you perform a cat < /dev/cuaU? (whatever number is giving you grief).
Is there any data coming out of it? (You might want to set up a separate terminal/session because it will likely lock up).

I had a quick glance at the code and it's trying to send a 'Y' to the port. So, can you do this as root to the port in question and does it respond?

You could use something like comms/minicom to test.

Also, what's the power requirements of these? 90+mA? Are these running off a hub, unpowered?

Can you post the dmesg output for these when plugged in?
 
I have tried connecting them directly to the computer, to a powered hub, and to an unpowered hub. The results were the same regardless of the connection. I think the power requirement is 96mA - usbconfig shows the following for the unpowered hub and the adapters.
Code:
ugen1.4: <Fresco Logic, Inc. USB2.0 Hub> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.5: <vendor 0x1a86 USB2.0-Ser> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)
ugen1.6: <vendor 0x1a86 USB2.0-Ser> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)
ugen1.7: <vendor 0x1a86 USB2.0-Ser> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)
ugen1.8: <vendor 0x1a86 USB2.0-Ser> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)
The dmesg output from the boot was:
Code:
uhub4 on uhub3
uhub4: <Fresco Logic, Inc. USB2.0 Hub, class 9/0, rev 2.10/1.00, addr 4> on usbus1
uhub4: MTT enabled
uhub4: 4 ports with 4 removable, self powered
ugen1.5: <vendor 0x1a86 USB2.0-Ser> at usbus1
uchcom0 on uhub4
uchcom0: <vendor 0x1a86 USB2.0-Ser, rev 1.10/2.54, addr 5> on usbus1
uchcom0: CH340 detected
ugen1.6: <vendor 0x1a86 USB2.0-Ser> at usbus1
uchcom1 on uhub4
uchcom1: <vendor 0x1a86 USB2.0-Ser, rev 1.10/2.54, addr 6> on usbus1
uchcom1: CH340 detected
ugen1.7: <vendor 0x1a86 USB2.0-Ser> at usbus1
uchcom2 on uhub4
uchcom2: <vendor 0x1a86 USB2.0-Ser, rev 1.10/2.54, addr 7> on usbus1
uchcom2: CH340 detected
ugen1.8: <vendor 0x1a86 USB2.0-Ser> at usbus1
uchcom3 on uhub4
uchcom3: <vendor 0x1a86 USB2.0-Ser, rev 1.10/2.54, addr 8> on usbus1
uchcom3: CH340 detected
with apcsmart running, cat from the working adapter returns 08
apcsmart terminates on the non-working adapters so cat doesn't return anything.
I will install comms/minicom later today to see if it will provide any additional information.

JJ
 
I know nothing of apcsmart, so let's get that disclaimer out of the way... :)

Is it possible to run a trace of apcsmart while it's connected to one of the dodgy UCH340s?

Code:
$ script apcsmart_debug.txt
$ truss `which apcsmart`
$ exit
This may give some insight into why it's failing, because it's obvious the system thinks they're CH340 devices, it can allow you to read from them but only 1 is successful in writing.
When I looked at the code, it performs a sort of buffered and paused write to the device which might not work on all serial to usb adapters and their internal microcode, ie it times out. In other words, it could be a special case bug in apcsmart. If you can get the output of the apcsmart failure on one device it might give some clue.

Actually, it probably wouldn't hurt to do it for one that works and one that doesn't. The more information, the better.
 
Another thing to consider is the hardware handshaking.
Years ago, I had to connect a notebook to a special purpose programmer device that relied on full hardware handshaking support.
I had to try out a number of USB-RS232 adapters/chipsets, until I found one that worked sufficiently reliable. I do not recall now whether the CH340 was a "good" or a "bad" one, just want to hint you at that potential problem...
 
For troubleshooting I would eliminate the hub and try with motherboard USB.
Use the hub for your keyboard/mouse instead.
Reason: All devices are on the same parent USB device 1.x

Another thing that is sticking in my brain is this;
My problem is that only one works. The other 3 fail with a "no write access" error message.
This would indicate that perhaps the others ports are locked?
 
After some searching I found this post that seems similar.

"no write access"
doesn't refer to a problem accessing the serial port, but to permission error on writing the lock file.
Forum posts give the hint to check /var/spool/lock... and indeed, there is the problem:

Just setting the group to dialer is not sufficient, as uucp is not part of the group dialer.
 

mark_j​

I ran the trace for the working (cuaU0) and non-working (cuaU1) devices and put the output in pastebin. The files are apcsmart cuaU0 and apcsmart cuaU1.
I don't know enough to understand them but it seems like they should show what fails and when.

Snurg​

Thanks for the thought. The fact that one works properly, the label is different on the one that works from the 3 that don't work, and all show only the expected differences with usbconfig -d ugen1.x dump_all_config_desc makes me think there is some type of hardware difference that I don't have the expertise to find.

Phishfry​

Thanks for the link. It looks like that particular problem was resolved. The install of 12.2 shows owner / permissions properly and the lock for the working adapter.
Code:
drwxrwxr-x  2 uucp  dialer  512 Feb 13 22:39 .
drwxr-xr-x  9 root  wheel   512 Oct 31  2019 ..
-rw-------  1 uucp  dialer   11 Feb 13 22:39 LCK..cuaU0
-rw-r--r--  1 root  dialer    0 Feb 12 19:33 clean_var
.
Is there a configuration that sets which devices can use the lock directory?
 

mark_j​

After a quick comparison of the trace output from the runs. The differences all look reasonable until the difference in the result of the select on line 263. Is that the timing problem you referred to?
 

mark_j​

After a quick comparison of the trace output from the runs. The differences all look reasonable until the difference in the result of the select on line 263. Is that the timing problem you referred to?
Yes (262 actually) but it's actually not sleeping according to your output. A cursory look at the code saw usleep(variable) so I assumed a greater than zero 'value'. I now looked closer in the code and it indeed calls usleep(0).

That said, it works for the other device, so quirks aside, this isn't a programming issue here.

At 263 it performs the select() and then times out (no data from the USB), so it sends an ESC (I don't know why but let's assume it's needed). Then it select() calls again, this time it returns data/error (the latter in fact). Then it tries the "Y" again and then seriously barfs on the attempt to write to the device because it's gone.

The logic in the code shows it will attempt this 5 times unless there's a serious error, so, it's doing what it should.

Is there any information in any logs about when it "goes away"? Anything in /var/log/messages?

I have one of these USB to Serial gadgets somewhere, let me dig it up and see if I can look into it's workings with FreeBSD. As I said, though, these devices (CH340) are poorly documented, poorly engineered clones of the FT232 and widely copied by the chinese. My experience is their internal voltage converters (5v [USB] to 9v [RS232]) are hit-and-miss. That's why, sometimes, I recalled better success with a powered hub.
 
Well I searched for some CH340s but I think they must have been thrown out. The only one I could find was the Prolific and it worked fine connected to an old RT200 APC. (I didn't use your software, I just used minicom to talk to it).

FreeBSD specs:
ugen0.4: <Prolific Technology Inc. USB 2.0 To COM Device> at usbus0
uplcom0 on uhub2
uplcom0: <Prolific Technology Inc. USB 2.0 To COM Device, class 0/0, rev 1.10/3.00, addr 4> on usbus0

So, I know it's not a solution to your issue with the hardware you've got, but can you source one of these cables? Give it a try?

They're black, box-like at the RS232 with a 1metre cable, similar to this: Prolific
 
mark_j

Thanks for the help. I am following your example and throwing these out too. I looks like, even if I could get these to work, they might not be reliable down the road. So I ordered a replacement and I'll see how it goes when it gets here.
 
As I said, though, these devices (CH340) are poorly documented, poorly engineered clones of the FT232 and widely copied by the chinese. My experience is their internal voltage converters (5v [USB] to 9v [RS232]) are hit-and-miss.
Yes I believe this is what I found out back then.
It took me some time to find some FT232 dongle, as these are quite rare to find.
Subjectively 99% crap like CH340, and very few originals.
I had to google a lot of spec sheets to make sure that the dongles were no CH340.
But when I got the part, all went smoothly, RTS/CTS+DSR/DTR+CD were all honored, problem gone.
 
mark_j

Thanks for the help. I am following your example and throwing these out too. I looks like, even if I could get these to work, they might not be reliable down the road. So I ordered a replacement and I'll see how it goes when it gets here.
That's ok.

Did you try using minicom and talking to the adapters you had? After all, it could be a timing thing with them, like flow control etc. (I guess, regardless, you want to use them with the sysutils/nut monitor software, so it's a moot point).

Those "prolific" ones are the only type that are used where I work, so they must be reliable and able to work with NetBSD (and that's where the drivers originally came from) and FreeBSD.

The prolific adapters we use are, however, not sourced off ebay, but they look the same. Beware, they might be junk inside if they come via ebay... YMMV. ;)
 
Yes I believe this is what I found out back then.
It took me some time to find some FT232 dongle, as these are quite rare to find.
Subjectively 99% crap like CH340, and very few originals.
I had to google a lot of spec sheets to make sure that the dongles were no CH340.
But when I got the part, all went smoothly, RTS/CTS+DSR/DTR+CD were all honored, problem gone.
True. Most people who encounter them find them junk.

However, I use a CH340-based UART Arduino UNO clone attached to a RPI3B running FreeBSD 12 and it's worked flawlessly. I just think those USB <-> RS232 are very poorly engineered. Period. You're best to pay extra and get non-CH340 in such an adapter.
 
Did you try using minicom and talking to the adapters you had?
No. I don't know what the ups expects and didn't want to send the wrong thing i.e. potentially modify something without knowing it. If you have a suggestion, I would like to give it a try.
 
I would have just pressed Y after minicom connected, because that's what your software does. If it answers or not would determine your next step. Perhaps it would answer and it's too quick for the software you're using and a bug report could have been raised to fix it?

Re your concern about typing garbage in: Most serial port protocols allow for garbage and just eat it. For example, you can connect at a different baud rate and it will just ignore it. I'm pretty certain UPSs don't come with a "self destruct" command... ;)

It's probably moot since you've disposed of the dodgy adapters anyway and moreover probably a waste of time.
 
Back
Top