0

I'm working on a small OS X app that connects to an FTDI device. I've configured my project according to the answer in this question (I've added the .dylib file as a framework, and I added the ftd2xx.h, WinTypes.h, and ftd2xx.cfg files to my project).

I'm currently able to detect if/when the FTDI device is connected over USB:

DWORD deviceCount = 0;
FT_STATUS ftdiPortStatus = FT_ListDevices(&deviceCount, NULL, FT_LIST_NUMBER_ONLY)
if (ftdiPortStatus == FT_OK) {
    // The debugger tells me the deviceCount is now 1
    ...
}

However, if I try to open a connection to the device using either of the following techniques:

ftdiPortStatus = FT_OpenEx("FT232R USB UART",FT_OPEN_BY_DESCRIPTION,deviceHandle);
// OR
ftdiPortStatus = FT_Open(0, deviceHandle);

the returned ftdiPortStatus is always 3 (FT_DEVICE_NOT_OPENED).

The answer here indicates that the problem might be a new driver that Apple added in OSX 10.9, however, if I attempt to unload that kext:

sudo kextunload -b com.apple.driver.AppleUSBFTDI

the OS indicates that no such kext was found. I'm on OSX 10.10, so maybe Apple repented of their ways and removed that driver from Yosemite(?) Either way, I'm still not able to connect... Does anyone have any idea what might be preventing the connection or have ideas for how I might track down the problem (the returned FT_STATUS isn't very helpful...)?


UPDATE:
The answer, below, solved the problem for me. If you are unsure as to whether you might have a second, non-Apple VCP driver installed, you can find the other drivers by running the following command in a terminal:

kextstat | grep FTDI

which will output something like this:

  154    0 0xffffff7f831ee000 0x8000     0x8000     com.FTDI.driver.FTDIUSBSerialDriver (2.2.18) <96 16 5 4 3 1>
  155    0 0xffffff7f831f6000 0x7000     0x7000     com.apple.driver.AppleUSBFTDI (1.0.1b12) <96 16 5 4 3>
Community
  • 1
  • 1
Troy
  • 21,172
  • 20
  • 74
  • 103

1 Answers1

3

No, that driver is still there on Yosemite. Running 

sudo kextunload -b com.apple.driver.AppleUSBFTDI

still removes the relevant kext and frees the device for access via the D2XX library on this Yosemite system I just tested. The kext may be missing if you haven't yet connected your FTDI device to the system.

It may also be blocked by another virtual comm port driver. If you've installed FTDI's virtual comm port driver, that will also take control of the port and block the D2XX library from connecting. Certain Arduino dev kits also use virtual comm port drivers for the FTDI chips they use, so they may have installed their own driver. Check for that.

Finally, the device name of "FT232R USB UART" that I use in my example code may not be the name of your device. There are many FTDI variants, and you'd need to make sure you're using the name of your specific type of device. This can be obtained from the FT_ListDevices() command with the FT_LIST_BY_INDEX|FT_OPEN_BY_DESCRIPTION options. If you use the wrong device name, FT_OpenEx() can fail.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
  • Thanks for the reply, Brad. Regarding the device name, I'm using the same check that you have in your example (and the other Open() function fails too), so I'm guessing there must be a conflict somewhere else. I remembered that I had installed the .dylib file in the /user/local/lib/ directory (according to the FTDI ReadMe instructions), so I removed it from there, but now the app crashes after launching because it, apparently, wants the lib to be at that location. Is it necessary for me to place it there also, or should it be sufficient to simply point Xcode to the .dylib in my project? – Troy Feb 11 '15 at 19:14
  • For the dylib thing, I believe I just have a general linking problem that I'll investigate. I am curious how you are handling the "com.apple.driver.AppleUSBFTDI" problem in production. Asking (non-tech-savvy) customers to uninstall the kext when they use the app doesn't seem very practical... Or are you, personally, just using the FTDI lib for internal apps? – Troy Feb 11 '15 at 20:42
  • @Troy - We created our kext that is totally blank, but which claims ownership to the FTDI devices we use. We sign that as a driver and deploy it as an installable package, which we run once on new systems we ship or which we have our customers run once on their systems as they upgrade to Mavericks / Yosemite. Regarding the .dylib, see the third and fourth paragraphs in my answer: http://stackoverflow.com/a/14446874/19679 . It needs to be bundled in the right place, and have its install paths modified. – Brad Larson Feb 11 '15 at 21:39
  • We still use the D2XX interface because Apple's virtual comm port has problems with latency, where the FTDI D2XX library lets you drop latency using a command. For our application, the default latency renders communication unusable, so we have to keep using the D2XX library. Other than having to install our fake driver once, it works great. – Brad Larson Feb 11 '15 at 21:41
  • So, just making sure I understand... you created a driver, separate from you app, that doesn't do anything but claim ownership of your device. And, by simply installing that driver, that prevents Apple's driver from hijacking the connection to your device? Then when you install your app/UI, it is able to make the connection directly (i.e. not using your installed driver)? – Troy Feb 12 '15 at 16:24
  • @Troy - Yes. It's a separate package from our application that just needs to be installed once. You will need special approval from Apple for this (your standard Developer ID certificate needs to be approved by them to sign drivers), but they have a template for blank drivers like this. Once the driver is installed, Apple's FTDI driver won't claim the devices and you can access them via the D2XX library as you would have before Mavericks. – Brad Larson Feb 12 '15 at 16:52
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/70801/discussion-between-troy-and-brad-larson). – Troy Feb 12 '15 at 16:55