OS X Mavericks (10.9): USB/Serial Driver Setup

It turns out that my Dick Smith Electronics USB/Serial adapter (link is to current model, XH8290; mine is an older pre-2009 model, the XH6381, with similar external look but possibly different internals -- probably from around 2007) still needs a driver like it did in OS X 10.6/Snow Leopard.

My USB/serial device is ProductId=0x0421 (1057), VendorId=0x0b39 (2873) -- which turns out to be important in getting a driver to recognise it. Like many of these USB/serial devices, it has a FTDI chip in it.

In theory Apple implemented a FTDI driver, as part of the IOUSBFamily.kext kernel extension (/System/Library/Extensions/IOUSBFamily.kext/Contents/Plugins/AppleUSBFTDI.kext). But it didn't work with my device, AFAICT because the ProductId/VendorId combination was not matched (not listed in "Info.plist" in the Contents of the Apple IOUSBFamily Plugin).

After a diversion trying an Open Source Prolific 2303 driver (before I realised the FTDI chipset is different from the Prolific 2303 chipset and thus it was never going to work; see below) I ended following the Arduino instructions to disable the Apple driver and install the FTDI driver:

Disable the AppleUSBFTDI.kext extension:

cd /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns 
sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled  
sudo touch /System/Library/Extensions

Reboot the computer, to ensure the AppleUSBFTDI.kext is not running
Download the Virtual Comm Port driver from FTDI (last version is 2.2.18, released 2012-08-10; for OS X 10.3 through OS X 10.9; their install instructions do describe how to install it on OS X 10.8 and 10.9, in a similar manner to this -- including disabling the Apple driver on OS X 10.9)
Open the FTDIUSBSerialDriver_v2_2_18.dmg disk image
Run the FTDIUSBSerialDriver_10_4_10_5_10_6_10_7 installer in the DMG file by holding down Control, clicking on the Installer icon, and choosing "Open", then confirming the Open (necessary because it is not signed; see below for more details)
Choose to install it to the "Macintosh HD", and enter credentials to allow the install to complete

Check it has installed and loaded the driver:

ls -ld `/System/Library/Extensions/FTDIUSBSerialDriver.kext`   
kextstat | grep FTDI

Check that the USB Serial device appears as expected:
```
ls /dev/cu.usbserial* /dev/tty.usbserial*
```

After that the USB/serial device should be usable again. For completeness, checking /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist confirms that there is a match for my 1057/2873 USB device:

<key>Dolphin USB to Serial Adaptor</key>
<dict>
    <key>CFBundleIdentifier</key>
    <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
    <key>IOClass</key>
    <string>FTDIUSBSerialDriver</string>
    <key>IOProviderClass</key>
    <string>IOUSBInterface</string>
    <key>bConfigurationValue</key>
    <integer>1</integer>
    <key>bInterfaceNumber</key>
    <integer>0</integer>
    <key>idProduct</key>
    <integer>1057</integer>
    <key>idVendor</key>
    <integer>2873</integer>
</dict>

which explains why it works with only this driver and not the Apple FTDI driver. (It looks like the Dolphin USB to Serial Adapter design dates back to 2002, and uses an older deprecated FTDI FT8U232AM chipset, which may be why Apple chose not to support it in their FTDI driver.)

ETA, 2014-10-24: FTDI released driver version 2.12.00 with code to overwrite the USB PID/VID of devices they considered 'fake' (speculated to be this code which looks plausible, and seems to do EEPROM writes that (many?) non-FTDI devices accept, but FTDI devices reject as being too narrow a write to be valid). They justify damaging other devices as permitted by the FTDI drvers terms of use, so it appears very deliberate.

The same change seems to have been proposed for the Linux driver, but was rejected as performance art. And someone proposed the Linux driver accept the overwritten PID/VID as matching the FTDI driver anyway.

It seems to me this means that (a) one should avoid installing the FTDI driver 2.12.00 or newer and (b) one should avoid buying anything reported as having a FTDI chip in it, because other than decapping the chips and imaging the silicon there does not seem to be any way to be certain, as an end-user, whether the device will be overwritten by the new FTDI driver or not. Maybe I do want Prolific 2303-based USB-serial devices after all (see below).

Something of an own goal, I think, FTDI. Zeptobars.Ru's suggestion to make the driver emit 'FAKECHIP' strings in place of the serial data (apparently made directly to FTDI reps, before the new driver release) seems like a much more legitimate self-help remedy to avoid their driver effort/reputation being harnessed by others -- and one that would not have led to people (legitimately, I think) calling the new FTDI drivers malware.

ETA, 2016-06-26: For future reference it appears it may be possible to repair the PID within Linux with something like:

Plug in your bricked device. If you run "lsusb" it should show a device at "0403:0000".
Download ft232r_prog (v1.25) from ft232r_prog (v1.24) and extract to a folder

Install the build dependencies by running:

sudo apt-get install make gcc libftdi-dev1

Change directory into the folder ft232r_prog where the file ft232r_prog.c resides
Type "make" to build the program
Now run sudo ./ft232r_prog --old-pid 0x0000 --new-pid 0x6001
You are done. Unplug and re-insert your USB device and run "lsusb" again. It should show an id of 0403:6001

perhaps given some modifications of the VendorID (and someone has done something similiar with a hacked version of the the FTDI Windows tool).

I have not tested this, but have kept a copy of it for future reference, since my latest install requires upgrading to a driver released in this problematic time period.

Also, guide to istalling OS X driver for CH340G used on some Arduino, etc, devices (Now available as a signed driver).

Prolific 2303 Open Source driver

Several people are using an Open Source project, OS X PL 2303 with their USB/serial devices, which supports the Prolific 2303 chipset. (The project has been around for several years and seems to be partly based on the Linux driver; and someone used that Lion version on Mavericks but there is also an OS X Mavericks 64-bit build now.)

Before I realised that the FTDI chipset and the Prolific 2303 chipset were different, I tried the OpenSource PL 2303 driver first since it had been updated more recently than the FTDI binary driver. Because I've already written up my installation notes for the Open Source driver, I'm including them below for completeness, even though it did not work with my USB/serial adapter (ProductId/VendorId do not match, and chipset does not match!). (Of note, there are several generic Prolific 2303 clones some of which play rather loosely with the RS232 standard.)

Installation of the Prolific 2303 Open Source driver for OS X Mavericks:

Download the latest OS X Mavericks build of the driver from the OS X PL 2303 site, currently 0.4.0. This gives NoZAP-Pl2303-10.9-installer.dmg.
Open NoZAP-Pl2303-10.9-installer.dmg. (The driver, a kext kernel extension is included as a resource of the Installer.)
Run the Installer in the DMG file by holding down Control, clicking on the Installer icon, and choosing "Open", then confirming the Open (this is necessary because the application is from an "unidentified developer" -- ie it hasn't been signed by an Apple Developer key).
The "Installer" is a three slide show screen advertising another project ("NoZap"), after "Next" on slide 2 it will copy the extension into /System/Library/Extensions and (apparently) try to load it (which will issue another warning about it being from an "unidentified developer" as it tries to load, but apparently not actually load it).

Go to /System/Library/Extensions and reset the permissions of the files:

cd /System/Library/Extensions
sudo chmod -R 755 NoZAP-PL2303-10.9.kext
sudo chown -R root:wheel NoZAP-PL2303-10.9.kext

Then manually load the extension and verify it loaded:
```
cd /System/Library/Extensions
sudo kextload ./NoZAP-PL2303-10.9.kext
kextstat | grep 2303
```
(there will be a warning for invalid signature.)
Plug in your USB serial device and check if it was recognised:
```
ls /dev/cu.* /dev/tty.*
```
If the device is matched there should be a "NoZap" device file listed.
If it was not listed, find the USB ProductId/VendorId (eg, via "About This Mac" system information), and check if they are mentioned in:
```
/System/Library/Extensions/NoZAP-PL2303-10.9.kext/Contents/Info.plist
```
If not, the driver will not be matched against the USB device.

Since mine was not matched -- and it turns out actually a different chipset -- I manually removed the kernel extension again:

cd /System/Library/Extensions
ls | grep 2303
sudo kextunload ./NoZAP-PL2303-10.9.kext
sudo rm -r NoZAP-PL2303-10.9.kext
sudo touch .

(The last step to tell inform the system caches that they need to be updated.)