MacOSX: Unable to open multiple interfaces from the same device

[www.google.com/accounts/o8/id?id=aitoawngvj0h9wvibnb9bo3uxkhlq4ozwwp5jfg]

I had an issue last year, see

​http://article.gmane.org/gmane.comp.lib.libusb.devel.general/7270

Nathan Hjelm sent me a patch by that time that solved the initial issue with
libusb 1.0.4

I've not been working on the USB related project for a while, and I've
just started back to use libftdi + libusb on my Mac.

I installed a new Mac with libusb-1.0.8, and I faced the very same
issue than last year.

I've spent some time seeking for the patch within the libusb git
repository, and it seems it has been integrated with other change in

e8d7a89503d5655c4b04da718c6971e25ff48162

(August 3rd '10) "Darwin: Cache device configuration value"
but I might be wrong.

If I'm not mistaken (I'm still a newbie with git), the patch has not
been integrated within the last official libusb release (1.0.8, May
5th '10)

I therefore tried to check out the head of the repository and build it.
On the way, I hit an issue with autoconf script, the libusb/Makefile
file is left with LDFLAGS empty, which leads the libtool to generate a
library that is not linked with the IOKit Framework, which in turn
leads to this error when the dynamic libusb library is loaded:

Symbol not found: _IOCreatePlugInInterfaceForService
 Referenced from: /usr/local/lib/libusb-1.0.0.dylib
 Expected in: flat namespace
 in /usr/local/lib/libusb-1.0.0.dylib

I've temporarily fixed up the LDFLAGS entry and rebuilt the library.

Unfortunately, I bumped into the very same, initial error when
accessing the FTDI USB device.
I've enabled the libusb DEBUG flags, here is the output:

Opening the first interface, everything is Ok:

libusb:info [event_thread_main] creating hotplug event source
libusb:info [event_thread_main] thread ready to receive events
libusb:info [process_new_device] allocating new device for location 0xfd000000
libusb:info [darwin_check_configuration] active config: 1, first config: 1
...
libusb:info [darwin_open] device open for access
libusb:info [darwin_open] device open for access
libusb:info [get_endpoints] building table of endpoints.
libusb:info [get_endpoints] interface: 0 pipe 1: dir: 1 number: 1
libusb:info [get_endpoints] interface: 0 pipe 2: dir: 0 number: 2
libusb:info [darwin_claim_interface] interface opened

Then the libusb client (that is libftdi) performs a USB control request:

libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling control completion with
kernel status 0
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling control completion with
kernel status 0

Once it's done, the code is repeated for the second interface of the
FTDI USB chip.

Opening the second interface seems Ok:

libusb:info [process_new_device] allocating new device for location 0xfd000000
libusb:info [darwin_check_configuration] active config: 1, first config: 1

libusb:error [darwin_open] USBDeviceOpen: another process has device
opened for exclusive access
libusb:info [darwin_open] device open for access
libusb:error [darwin_open] USBDeviceOpen: another process has device
opened for exclusive access
libusb:info [darwin_open] device open for access
libusb:info [get_endpoints] building table of endpoints.
libusb:info [get_endpoints] interface: 1 pipe 1: dir: 1 number: 3
libusb:info [get_endpoints] interface: 1 pipe 2: dir: 0 number: 4
libusb:info [darwin_claim_interface] interface opened

Note that the log message is somewhat unexpected, as this is the very
same process that opened the first interface.

On the first control request, the following error occurs:

libusb:error [submit_control_transfer] control request failed: no
async port has been opened for interface

The actual control request that fails comes from the libtdi request
and looks like the following:

libusb_control_transfer(ftdi->usb_dev, FTDI_DEVICE_OUT_REQTYPE,
                               SIO_RESET_REQUEST, SIO_RESET_SIO,
                               ftdi->index, NULL, 0, ftdi->usb_write_timeout)

I double check the same client code on Linux: no trouble with libusb-1.0.7

It seems to be an issue for the Mac OS X backend only.

[hjelmn]

Try Peter's git tree (​http://git.libusb.org/?p=libusb-stuge.git;a=summary;js=1). It has all the latest OS X related patches. Let me know if it still doesn't work.

[www.google.com/accounts/o8/id?id=aitoawngvj0h9wvibnb9bo3uxkhlq4ozwwp5jfg]

Very same issue with Peter's git tree.

libusb:error [darwin_open] USBDeviceOpen: another process has device opened for exclusive access
libusb:info [darwin_open] device open for access
libusb:error [darwin_open] USBDeviceOpen: another process has device opened for exclusive access
libusb:info [darwin_open] device open for access
libusb:info [get_endpoints] building table of endpoints.
libusb:info [get_endpoints] interface: 1 pipe 1: dir: 1 number: 3
libusb:info [get_endpoints] interface: 1 pipe 2: dir: 0 number: 4
libusb:info [darwin_claim_interface] interface opened
libusb:error [submit_control_transfer] control request failed: no async port has been opened for interface

BTW I'm still unable to compile it out-of-the-box, as the link flags to not reference th IOKit framework:\
for some reason AM_LDFLAGS is defined with the proper values, but libtool seems to use LD_FLAGS which is left blank. If LD_FLAGS is forced with the AM_LDFLAGS value, the generated libusb dylib seems ok.

Maybe the client (libftdi) is doing something wrong, however the same call sequence works with Linux.

[www.google.com/accounts/o8/id?id=aitoawngvj0h9wvibnb9bo3uxkhlq4ozwwp5jfg]

It actually comes from some invalid call of libftdi.

Using pyftdi + pyusb (on top of libusb, bypassing libftdi), I can successfully open two serial ports at once on the remote USB device.

Sorry for the trouble.

[stuge]

Thanks for the report.

The LDFLAGS issue should be fixed in a proposed patch: ​http://marc.info/?m=129298531219122