3

I'm using Ubuntu 18.10 x64 on my laptop and 17.10 x64 on another machine. The info below comes from the 18.10 laptop, but both have the same issue.

I've attached a USB-to-Serial board (a Chinese TI SmartRF04EB clone, using an equivalent to a Silicon Labs C8051F320 MCU to provide a USB interface) wired to a Chipcon 8051 development board but /dev/ttyUSB0 etc is not created which I need to issue debugging commands to the board e.g. over a moserial terminal.

Can you suggest why the /dev/ttyUSB entry is not being created automatically, and how I can ensure that it is?

Thanks in advance.

Background

I can connect from a Windows VM in VirtualBox and read the registers on the development board, but not from my host machine. The Chipcon device is the USB-Serial adapter board, as I get the same results if the 8051 development board is disconnected.

MacBookPro:~$ lsusb
Bus 001 Device 012: ID 11a0:eb20 Chipcon AS

Dmesg shows the device is recognised:

MacBookPro:~$ dmesg | grep 1-1.1:
[ 1989.355072] usb 1-1.1: new full-speed USB device number 12 using xhci_hcd
[ 1989.468502] usb 1-1.1: New USB device found, idVendor=11a0, idProduct=eb20, bcdDevice= 0.50
[ 1989.468505] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1989.468506] usb 1-1.1: Product: SmartRF04EB
[ 1989.468508] usb 1-1.1: Manufacturer: Chipcon AS
[ 2006.115847] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 2036.516953] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 2058.765773] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 2105.307403] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 4370.664093] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[64333.681207] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd

But there is no /dev/ttyUSB entry, or any other entry immediately under /dev/ or /dev/usb/:

MacBookPro:~$ ls /dev/ttyUSB*
ls: cannot access '/dev/ttyUSB*': No such file or directory

An entry is created at /dev/vboxusb/001/012 when the device is plugged in, which allows a Windows VM to talk to the device. The number changes when it's reconnected, but doesn't affect the VM.

The driver is listed by usb-devices as None:

MacBookPro:~$ usb-devices
...
T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 12 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=11a0 ProdID=eb20 Rev=00.50
S:  Manufacturer=Chipcon AS
S:  Product=SmartRF04EB
C:  #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

A simple Udev rule, suggested elsewhere, made no difference:

MacBookPro:~$ cat /etc/udev/rules.d/99-usb-serial.rules
# SmartRF05 Evaluation Board
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a0", MODE="0666"

# SmartRF04 Evaluation Board
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="11a0", ATTRS{idProduct}=="db20", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="11a0", ATTRS{idProduct}=="eb20", MODE="0666"

# CC Debugger
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a2", MODE="0666"

I added myself to the tty and dialout Groups, without effect.

Running udevadm:

MacBookPro:~$ sudo udevadm test -a -p $(udevadm info -a udevadm info -q path -n /dev/bus/usb/001/012)
calling: test
version 239
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
Reading rules file: /lib/udev/rules.d/39-usbmuxd.rules
...
Reading rules file: /lib/udev/rules.d/99-systemd.rules
rules contain 393216 bytes tokens (32768 * 12 bytes), 40208 bytes strings
32422 strings (271011 bytes), 28868 de-duplicated (234358 bytes), 3555 trie nodes used
IMPORT builtin 'usb_id' /lib/udev/rules.d/50-udev-default.rules:13
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:13
handling device node '/dev/bus/usb/001/012', devnum=c189:11, mode=0600, uid=0, gid=0
preserve already existing symlink '/dev/char/189:11' to '../bus/usb/001/012'
ACTION=-p
BUSNUM=001
DEVNAME=/dev/bus/usb/001/012
DEVNUM=012
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=SmartRF04EB
ID_MODEL_ENC=SmartRF04EB
ID_MODEL_ID=eb20
ID_REVISION=0050
ID_SERIAL=Chipcon_AS_SmartRF04EB
ID_USB_INTERFACES=:ffffff:
ID_VENDOR=Chipcon_AS
ID_VENDOR_ENC=Chipcon\x20AS
ID_VENDOR_FROM_DATABASE=Chipcon AS
ID_VENDOR_ID=11a0
MAJOR=189
MINOR=11
PRODUCT=11a0/eb20/50
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=1989348663
Unload module index
Unloaded link configuration context.

The USB entry in line 13 on of /lib/udev/rules.d/50-udev-default.rules:

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"

ACTION!="add", GOTO="default_end"

1 Answer 1

1

Three changes solved the problem:

  1. Replugging the JTAG cable. For some reason the connection appeared to have been faulty, as cc-tool then recognised the development board.

  2. Editing the 6th line in the udev rule with the addition of a Symlink to ttyUSB0 to read:

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="11a0", ATTRS{idProduct}=="eb20", MODE="0666", SYMLINK="ttyUSB0"

  1. Rebooting the laptop to reload udev rules; attempts to use udevadm didn't create the symlink:

udevadm trigger

udevadm control --reload-rules

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .