# Problem accessing serial device through USB

## PQPGuy

I'm a complete n00b when it comes to serial devices, and I need to get one working, so please be patient.  The device is connected through a USB cable and shows up via lsusb as

 *Quote:*   

> Prolific Technology, Inc. PL2303 Serial Port

 

I have the usbserial module loaded, so now dmesg says

 *Quote:*   

> usb 4-2: Manufacturer: Prolific Technology Inc.

 

The problem is that setserial -g /dev/ttyS[0123] says UART: unknown for each port.  What should I do to be able to access this serial port?  Any driver is missing?  Do I need an fstab entry for this?  Again, I'm just starting in this subject, so any suggestions are welcome.

Many thanks.

----------

## eccerr0r

Probably would be best to describe your exact situation - what software, what hardware.

If you have your USB serial driver in the kernel installed properly along with udev setup, you should get a /dev/ttyUSB[0123...] or something like this.  You should be able to just use it as-is, no need to setserial them.

/dev/ttyS[0123] usually refers to onboard serial ports at io 0x3f8 0x2f8 0x3e8 0x2e8 and use the 8250/16450/16550 driver.  If you attempt to setserial them and the actual chip doesn't exist, it will say UART: unknown.

----------

## NeddySeagoon

PQPGuy,

I have one of those. lsmod tells me

```
pl2303                 20480  0

usbserial              28672  1 pl2303
```

You need the pl2303 kernel module too.

----------

## PQPGuy

NeddySeagoon, great advice.  There is no doubt I was missing pl2303.  Sadly, I still haven't solved the problem.

eccerr0r, I am using systemd, and this hardware piece is extremely custom-made, so I don't think you would have heard of it.  It's an access control device.  That thing that you put on an entrance door, which asks you to enter an access code before unlocking.

But you said that udev must also be configured.  What kind of configuration is it?

Finally, what do you mean by accessing it "as is"?  Would it have a mount point, or otherwise act similarly to an ordinary USB device?

Many thanks.

----------

## NeddySeagoon

PQPGuy,

You should have /dev/ttyUSB0 if your kernel is in good shape.

dmesg will tell if all the bits are loading.

Notice that 

```
ls /dev/ttyUSB* -l

crw-rw---- 1 root uucp 188,  0 May 12  2013 /dev/ttyUSB0
```

the device is restriced to root and members of the uucp group.

Check your /dev/ttyUSB0 and add your normal user to whatever group you have there.  It might not be uucp for you.

Until you get the /dev entry, nothing else matters.

By way of testing.  Connect the Tx and Rx lines together on the PL2303 and talk to yourself with minicom, or a terminal emulator of your choice.

----------

## eccerr0r

Ah, don't need to get extremely detailed, but knowing what you're trying to do in general would be helpful. 

As people have all sorts of different configurations on Gentoo machines, I had to ask.  Some people don't use udev, some treat systemd like the plague.

So if you have systemd working, udev came along for the ride and you don't need to worry about it.  Udev will create the /dev/ttyUSBx where x is a number, starting with 0, when you plug in the device.  The device will not show up until then (and your drivers are in place.)

As Neddy says, ensure that you have permissions to the correct device.  If you're using root for now, this shouldn't be a problem.

In any case, serial devices, like /dev/ttyS0, /dev/ttyUSB0, /dev/tty1 are known as "character" devices as witnessed by the "c" in the first column when you "ls -l" it.  These devices are meant to be fed into the program directly - no need to mount it.  Ideally that program knows how to configure it for like baud rate, parity, stop bits, etc.   If you're planning to write your own, yes you'll need to code that into your program but you'd be accessing the device directly and not as a mount like block devices like hard drives - indicated by the "b" in the first column of "ls -l".

----------

## NeddySeagoon

eccerr0r,

There is a whole learning experience that comes with getting a serial link up.

I wasn't going to discuss baud rates, parity, data bits and handshaking yet.

I was waiting for reports of sending and receiving in loopback first.

The PL2303 does not support hardware handshaking, so that one complication down.

----------

## eccerr0r

Indeed it is a whole learning experience, I hope that one would be somewhat aware of these issues when dealing with old classic serial devices, but it is a distinguishing characteristic of these serial ports that is best handled within the software versus a cooked "mount" interface where you could possibly work with it simultaneously outside of the software tool...

But since it was asked... no, you don't mount character devices.

----------

## NeddySeagoon

PQPGuy,

There are all sorts of incompatible serial devices. Some will even destroy others.

A long time ago, they were used in mechanical teletypes. The electrical interface was a 20mA current loop.

(Usually >±20v)

Then there was a ±12v version, later a ±5v version, then a 5v only version and today a 3.3v only version.

The PL2303 is a 3.3v device.  I use it for a serial console on a Raspberry Pi.

Its probably 5v tolerant, I've not tested.

All the other variants will destroy the  PL2303 on contact.

You need to check before you connect.

----------

## PQPGuy

Thank you both hugely!  Unfortunately, I'm not seeing any dev/ttyUSB*.  That's why I asked about possibly configuring udev.  I really, don't know much about that device other than the fact that it's PL2303 and was previously accessed the same way.

Is it conceivable that this is such an exotic PL2303 corner that no modern driver would support it?

----------

## NeddySeagoon

PQPGuy,

Its more likely you messed up your kernel install.

What does 

```
uname -a
```

say?

```
$ uname -a

Linux NeddySeagoon_Static 4.12.3-gentoo #1 SMP PREEMPT Wed Jul 26 14:01:32 BST 2017 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux
```

The Wed Jul 26 14:01:32 BST 2017 is the build date/time of my running kernel.  You have been building yours recently, it should show that.

If not, did you forget to mount /boot for the kernel install?

----------

## Hu

You say that you were missing pl2303, but that the problem remains.  Please describe what you changed that you believe should have resolved the absence of pl2303.  Did you build it as a module or build a new kernel with it built-in?  As Neddy suggests, verify that you are actually running the kernel you built with the fixed configuration.  If you are, verify that the new driver is loaded.  Have the observed symptoms changed since you added pl2303?  Perhaps you had two problems, and now that one is fixed, you can see the other.

----------

## PQPGuy

Some limited progress here.  I do see /dev/ttyUSB0 as non-root.  setserial -g /dev/ttyUSB0 prints  *Quote:*   

> /dev/ttyUSB0, UART: 16654, Port: 0x0000, IRQ: 0.

  Minicom displays something like 115200 8N1 which looks reasonable.  The problem is cat /dev/ttyUSB0 hangs without any output.  Is this normal?

NeddySeagoon, per your suggestion, how I can try to communicate with the device?  Is there some standard command, like PowerUP or PowerDOWN that I could issue to make the device respond in a certain way?

Many thanks.

----------

## NeddySeagoon

PQPGuy,

Where do you expect the Rx serial data to come from?  

That's what cat is waiting for.  I would say that its normal.

To start with, connect the Tx data to the Rx data on the PL2303.  Now start minicom.

Point minicom to /dev/ttyUSB0.  Turn off hardware and software handshaking.

The baud rate, parity and stop bits don't matter yet.  The PC has a long history of not supporting split baud rates.

Type into minicom. Everything you type should be echoed back to you.  Maybe twice.

If local echo is on in minicom, you will see your typing echoed once (locally) and again over the Tx Rx loop back.

If you break the Tx/RX link that echo will stop.

If that works. The PC end is almost set up.  It needs the 115200 8N1 set to match your other device.

----------

## eccerr0r

For RS232 devices, there are no standards in protocol.  The only RS232 standard is physical and electrical (which incidentally, if it can't accept negative voltages and can be damaged by shorting to +12 volts, does not meet RS232 standards.)

I'm assuming now you have a regular USB dongle and not a DIY bare PL2303 device.  If so, you can do a lot more experimentation than with a raw header that's logic level.  But even then it's still like a black box, you don't know the command sequence.

As above we can help with testing the computer serial port side of things to ensure it works.  However that device, if it's custom, you're on your own to figure out how to work it (disassemble reverse engineer? They hopefully aren't too complicated.).  If it's an off-the-shelf device, perhaps some research can be done to figure out the protocol (brand? model?).  If you have a Windows program, that could be helpful too.

I'm not sure what lead to the conclusion the device is a rs232 serial device.  Having a DB9 connector is no guarantee it's a serial device especially if it's a one-off device.

----------

## PQPGuy

The way this thing was set up, I've been told, is that, in the very beginning, it should send some self-diagnostics messages.  That's why I kind of wondered if cat ought to show something.

Also, going through some leftovers from the previous user, it appears that two of the commands he used were  *Quote:*   

> VERSION
> 
> 8

  or  *Quote:*   

> SEND
> 
> 2
> 
> !L1 LED off
> ...

 

Is this what I should be typing into the terminal and expect something back?

----------

## NeddySeagoon

PQPGuy,

Have you set up the serial link parameters correctly?

You mentioned 115200 8N1, do you know that's right?

If not you will either get nothing or jibberish on the link.

There is no standard for random devices, unlike the Hayes Command Set for modems.

We need to know what you are trying to communicate with.

----------

## eccerr0r

cat-ting the device won't likely result in anything as the serial link needs to be configured such that the bit rate, framing, and parity bits match that of the device that's being communicated to; not only that, the handshaking might not match.  I believe Linux resets communication parameters when the port is closed so when it's opened via cat, it will be fresh and likely wrong.

An invaluable tool to "play" with a serial device is a dumb terminal emulator such as net-dialup/minicom where you can set the bit rate, framing, and parity bits to match your device on the fly.  The dumb terminal emulator is actually the same as what xterm does to a pty, you get all the bits from the device displayed as text on your screen and everything you type gets sent to the device.  Not only this, it's always monitoring the serial line so you can turn off and on the device to see if it evokes a response on powerup.

Perhaps the first thing that needs to be done after you get minicom merged and your /dev/ttyUSB0 to show up is to test minicom itself to ensure at least this half of the channel is working.  Then you can experiment with the bit rate and framing (which the cryptic strings like 115200,8,n,1 and 2400,7,e,1) stuff will come in.

It seems you should be able to type those commands into minicom and evoke a response however.

----------

