Posts: 2
Joined: Mon Aug 25, 2014 3:35 pm

RPI B+, /dev/ttyUSBx names changes after reboot

Tue Aug 26, 2014 8:25 am

Hi guys,

the raspberry pi B+ works fine, but after a reboot, the /dev/ttyUSBx names were swapped.

My OS is the standard OS rasbian with the latest update and upgrade (2 weeks old).
I use 3 usb to serial converter, one for RS232, one for RS485 and one for I2C and one usb hub.
They are mapped to /dev/ttyUSB0 .. /dev/ttyUSB2. I also use Tcl/Tk to read from the serial converter. It works fine until the first reboot.

My problem is, after the first reboot the name of the first converter, which was ttyUSB0 before, is now ttyUSB1. the behavior of the 2nd and 3rd usb port are the same even if the usb hub is connected or not. Their names changes from ttyUSB1 to ttyUSB2 and from ttyUSB2 to ttyUSB0

After a second reboot, the names were swapped again. ttyUSB1 becomes ttyUSB2 and ttyUSB2 becomes ttyUSB0 and so on.

After the third reboot, the names were swapped again. In this case the names are the same like in the beginning and my software is able to work again.

the names should be the same after each reboot.
What is going wrong and how can I solve this problem?

Best regards

this is my configuration:
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
|__ Port 2: Dev 4, If 0, Class=vend., Driver=pl2303, 12M
|__ Port 3: Dev 7, If 0, Class=stor., Driver=usb-storage, 480M
|__ Port 4: Dev 5, If 0, Class=vend., Driver=ftdi_sio, 12M
|__ Port 5: Dev 6, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 4: Dev 8, If 0, Class=vend., Driver=cp210x, 12M

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 007: ID 8644:8003
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 008: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light

User avatar
Posts: 3426
Joined: Tue Oct 11, 2011 8:38 pm

Re: RPI B+, /dev/ttyUSBx names changes after reboot

Tue Aug 26, 2014 12:57 pm

udev should already be making persistent names in /dev/serial/by-id/. Use those, instead of hacking your own rules.

(In a case where the devices were identical models, there is /dev/serial/by-path/ too, which should be stable based on the port each device is plugged into.)

Posts: 2
Joined: Mon Aug 25, 2014 3:35 pm

Re: RPI B+, /dev/ttyUSBx names changes after reboot

Tue Aug 26, 2014 2:24 pm

that works fine.
thank you markus

Posts: 37
Joined: Thu Jul 17, 2014 5:08 am

Re: RPI B+, /dev/ttyUSBx names changes after reboot

Tue Nov 29, 2016 1:14 am

The multiple-identical-USB-device problem

I have a Rasperry Pi with four cameras. I take pix with fswebcam which identifies the cameras as /dev/video0 .. video3. I need a persistent ID identify a camera number so that (eg) video0 is always the same one. Unfortunately this doesn’t happen reliably – on boot, the cameras get enumerated as video0..video3 but not always the same way.

The solution to all of this is to use udev rules.

If you issue the command [udevadm info –attribute-walk –path=/dev/video0] you get a screed of output but the salient bits are KERNEL=”video0”, SUBSYSTEM=”video4linux” and KERNELS=”1:1.2.4:1.0”. The KERNELS bit is a USB hub port number. With four cameras there are four of these - the port numbers do not change on reboot , but the videox that a port goes with MAY change. So we need a udev rule to tie a video number to a port - something like

Looks simple – access the camera with [fswebcam –d $realpath /dev/camera0].

Except it doesn’t work – if you put this in a udev rule and the system allocates video0 (on boot) to a different port, the udev rule is ignored. The symlink to /dev/camera0 basically says “no such device”. Square one.

What we want is to bind a symlink to a USB hub address, not a videox number. It took a Python program.

First step was to run [fswebcam –d /dev/videox tst.jpg]for x between 1 and 8. The existence of tst.jpg after each call identifies whether there is a camera on this video number. From this make a list of active video numbers. My experience has been that it is either 0,1,2,3 or 0,2,4,6 for cameras I have used.

Then for each video number in the list run [udevadm info –attribute-walk –path=/dev/videox > dd]. Open the dd file and extract the KERNELS= line. From this process you end up with a list of the USB port addresses for the cameras. Sort this list so that at the next step, you always process it in the same order. Call this the “address list”

Run the [udevadm … > dd] thing again and make a list that looks like
KERNEL==”video0”, SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0 ”,SYMLINK+=”camerax”
Call this the “video list”.

Step through the address list and for each entry find the corresponding entry from the video list. Create a new list that looks like a collection of lines like
KERNEL==”video0”, SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0 ”,SYMLINK+=”camera2”
The x is replaced by the sequence number in the address list.

Now you have a udev rule that works. A symlink that is tied to a USB hub address no matter what video number is allocated to that port at boot. Write the final list into a file /etc/udev/rules.d/cam.rules. Run [udevadm trigger] to activate it and the job is done. Now $realpath /dev/camera2 is the same (camera) (USB port) regardless of whether it is video0,1,2 or 3.

Run the program as part of the boot sequence ....

Return to “Troubleshooting”