USB-Serial adaptor doesn't create /dev/ttyUSB path to address device

Question

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"

Solution

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"

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

udevadm trigger

udevadm control --reload-rules