Serial port troubles

JT42

JT42

I'm having trouble getting a serial port to work in FreeBSD 13.1-RELEASE-p3 GENERIC. I've tried three different configurations.

1) I borrowed a USB-to-RS232 adapter from my employer and it works. It has no brand name or model number printed on it, but FreeBSD detects it just fine:
ugen3.2: <FTDI UC232R> at usbus3 uftdi0 on uhub1 uftdi0: <UC232R> on usbus3

It appears as /dev/cuaU0.

2) I bought a Keyspan USB-to-RS232 adapter since (historically) they were known for quality. It is a Keyspan model USA-19HS. FreeBSD sees the USB device but apparently doesn't know what to do with it:
ugen3.2: <Keyspan, a division of InnoSys Inc. Keyspan USA-19H> at usbus3

When I plug it in, no cua* devices appear in /dev. I tried setting hw.usb.template to 3 and re-inserting the device, but still no luck.

3) I also tried a PCI-e 2-port card. It gives the appearance that it should work, but so far it doesn't. It's a Vantec model UGT-PCE20SR:
pcib4: <ACPI PCI-PCI bridge> at device 2.0 on pci2 pci4: <ACPI PCI bus> on pcib4 puc0: <Exar XR17V352> mem 0xfca00000-0xfca03fff irq 30 at device 0.0 on pci4 uart2: <16x50 with 256 byte FIFO> at port 1 on puc0 uart3: <16x50 with 256 byte FIFO> at port 2 on puc0

It gives me /dev/cuau2 and /dev/cuau3. I get nothing out of either port.

I am testing the port by connecting it to my RS232 device (a ham radio modem) and attempting to talk to it using minicom. I've only been able to get it to work in configuration #1 using the no-name USB-to-RS232 adapter. Unfortunately, that doesn't belong to me and I need to return it.

I've been to the serial comms section of the handbook but it hasn't helped.

Configuration #3 looks like it's close to working since it actually recognizes the card and creates the ports. I don't know why I can't get them to send or receive anything, though.

Any thoughts on what I could try?

Alternatively, does anyone know a brand and model of PCI-e serial port card that is known to work with FreeBSD?
 
Try this for Keyspan USB: kldload umodem. Then run tail -F /var/log/messages and plug the device in.

If it gets recognized, set it to automatically load the module by adding to /boot/loader.conf
Code: 
umodem_load="YES"

Or load it in rc.conf: sysrc kld_list+="umodem"
 
No dice with kldload umodem and the Keyspan unit.

I've ordered the UGREEN unit and will report back once it arrives.
 
While waiting for new hardware to arrive, I've been doing more investigating with option #3, the PCI-e card with two ports. There are at least two problems with it. One, it sends data at the wrong speed. I modified the clock reference for this device in /usr/src/sys/dev/puc/pucdata.c from 125000000 to DEFAULT_RCLK, rebuilt puc.ko, and that solved the speed problem.

The second problem (with or with my modified module) is that it sends a single character and then stops. It appears to be buffering the characters I type in minicom, but they don't get sent on the port. Here's the output of pstat -t before and after pressing a key in minicom (virtual ttys removed for clarity):

Before:
Code: 
      LINE   INQ  CAN  LIN  LOW  OUTQ  USE  LOW   COL  SESS  PGID STATE
     ttyu2     0    0    0    0     0    0    0     0     0     0 IC
     ttyu3  3840    0    0  384  3968    4  397     6     0     0 ICOol

After pressing another key:
Code: 
      LINE   INQ  CAN  LIN  LOW  OUTQ  USE  LOW   COL  SESS  PGID STATE
     ttyu2     0    0    0    0     0    0    0     0     0     0 IC
     ttyu3  3840    0    0  384  3968    5  397     6     0     0 ICOol

Any idea why this might be happening? The data sheet for the XR17V352 claims that both ports are 16550 compatible, so in theory the uart driver should be happy.

Also, does anyone have any idea why it would show up as /dev/cuau[2-3] instead of /dev/cuau[0-1] when the only UARTs in the system are on that card?
 
Have you tried commenting out or adjusting the uart settings in /boot/device.hints ?
They might be reserving the lower uart addresses.
 
_martin said:
I use UGREEN USB to RS232. Bought it from a local shop but pasting Amazon link here. I never had any issues with it anywhere including FreeBSD.
Click to expand...
It arrived today and appears to work. I noticed it has a Prolific chip (PL2303) instead of one from FTDI. In the distant past, people have had issues with Prolific USB-to-serial interfaces when using the software I'm trying to use (comms/xastir). Hopefully those issues have been resolved, but I have another one with an FTDI chip on order just in case. Thanks for the assistance.
 
I use cu(1) and don't have any problems with it. I think I did test it with minicom too. But cu is just more handy for my use.

I do see small difference in behavior compared to a direct connection of two built-in serial ports (16550 or compatible ones). The difference is when I execute cu from a server and client didn't initialize the port yet nothing happens. Even if server starts to send data (keyboard output), nothing happens, cu command waits. Once client initializes serial port connection is working just fine.

With this cable (port is on server side) if I do this I get connection disconnect. I need to re-execute cu command again.
I didn't go deep into this issue. I remember seeing this even if flow control is disabled in cu.
 
_martin said:
With this cable (port is on server side) if I do this I get connection disconnect. I need to re-execute cu command again.
I didn't go deep into this issue. I remember seeing this even if flow control is disabled in cu.
Click to expand...
Cable might have DTR/DSR connected. There are various ways to create a "null-modem" cable, 3, 5 or 7 wires. 3 wire only has ground and TxD/RxD crossed, 5 wire adds RTS/CTS to this, 7 wire also adds DTR/DSR.

en.wikipedia.org

Null modem - Wikipedia

en.wikipedia.org en.wikipedia.org
 
I use cu exclusively and I have not seen that problem.
I know exiting can be a impossible on some computers. To the point that I just reboot my serial server.

I do see one weird effect on a certain keyboard. It sends a weird couple characters on first input.
So much so that I just hit enter automatically because it corrupts the command.
I need to check it out. It is very reproducible. Only under cu. Zippy EL-715 keyboard.
 
SirDice said:
Cable might have DTR/DSR connected.
Click to expand...
I don't know which pins are actually connected but I don't have this problem when using the same cable on boxes directly. I suspect line reset is sent by ugreen cable itself; but that's just my opinion based on nothing pretty much.
I use it during debugging sessions where my focus is elsewhere. I consider that "issue" meh.
 
You must log in or register to reply here.
Back
Top