I recently wasted a few hours getting this to work. So documenting.

Problem

Getting an Adafruit Metro Mini recognised on a fresh-ish macOS install. The current revision of the board uses the SiLabs CP2104 chip, which requires a driver under macOS. I believe this chip is also used in a few other popular devboards. This is documented on Adafruit’s site (above link). However, this was broken for a few reasons. Net result is that though the driver appear to install correctly, plugging in the chip does not yield a serial port cu.SLAB_USBtoUART.

There’s a couple of posts/forum threads about it, but none, by themselves, helped me resolve this.

The causes

As usual with these things, a bunch of things conspired to make this difficult. The two main drivers:

  • v5 of SiLabs’ CP210x USB to UART driver is/was incorrectly signed. This might have been fixed now, but I used the v4 driver (labeled Legacy MacVCP Driver) in the download.
  • In macOS 10.13, Apple changed some security stuff around System Extension things, detailed here. This only affects new extensions. Ones already installed are grandfather-ed in.

Solution

  1. Make sure existing extensions are uninstalled. ls /Library/Extensions/SiLabs* should show you what’s there. You can then sudo rm -rf /Library/Extensions/SiLabsUSBDriver64.kext etc.
  2. Reboot. Check they are gone.
  3. Install the v4, legacy driver from the above link. v5 might be fixed now, but there were no compelling reasons to move to it for me.
  4. Reboot. Go to System Preferences => Security and Privacy You should see a message along the lines of “System software from developer ‘Silicon Laboratories Ltd’ was blocked from Loading”. Click “Allow”
  5. The previous step didn’t do anything for me. As it turns out, this particular screen check if there’s any mouse automation software active, and does not allow loading of said extensions if that’s the case. To find out what’s going on, open Console.app from spotlight. Keep the logs where you can see it. Now, click on the “Allow” button again. You should see a log line about something beign disallowed because it came from the wrong PID. Look this PID up in Activity Monitor. In my case, it was Chrome, which had the Chrome Remote Desktop plugin installed. Killing Chrome and clicking on “Allow” again worked.
  6. Plug your CP2104 board in again, and check for /dev/cu.SLAB_USBtoUART. If it’s there, you should be ready to go.

Parting thoughts

This whole thing seems to be a casestudy in why silent faliures are bad. Unless you go quite deep, there’s no “This didn’t work” dialogs. Just no expected effect. Further more, the macOS update didn’t break any existing setups, so this wasn’t immediately linked to the OS update.