Analog Discovery 2 Mac USB driver blocks serial USB devices

[albert]

Hello, I have an issue similar to this one, but not related to USB hubs:

Basically, after I installed Waveforms and the USB driver, I can no longer connect to the serial USB device that I am trying to debug! I am forced to kextunload and then kextload again to make them connect:

➜  ~ ls /dev/tty.*
/dev/tty.Bluetooth-Incoming-Port /dev/tty.lpss-serial1            /dev/tty.lpss-serial2
➜  ~ sudo kextunload /Library/Extensions/DigilentFtdiDriver.kext
➜  ~ ls /dev/tty.*
/dev/tty.Bluetooth-Incoming-Port /dev/tty.lpss-serial1            /dev/tty.lpss-serial2            /dev/tty.usbserial-1412A         /dev/tty.usbserial-1412B
➜  ~ sudo kextload /Library/Extensions/DigilentFtdiDriver.kext
➜  ~ ls /dev/tty.*
/dev/tty.Bluetooth-Incoming-Port /dev/tty.lpss-serial1            /dev/tty.lpss-serial2            /dev/tty.usbserial-1412A         /dev/tty.usbserial-1412B

Is there any way to fix this? The other devices are using the generic FTDI VCP driver. My computer is the latest MacBook Pro 15".

[attila]

Hi @albert

I thought you already got the new version fixing the OS-X driver re-installation problem...

Now you have it in private message. It is suffice to reinstall the driver from the package.

Let us knot if this helps.

[malexander]

Hi Albert,

This shouldn't happen unless your serial device is reporting information that causes the driver to think it's a Digilent device. When our driver is loaded and you plug-in a device our probe function gets called. There we read the manufacturing string from the string descriptor and check to see if it's "Digilent". If it's not, then we return a probe score of 0, which should cause OSX to continue looking for a matching driver. If the manufacturing string is "Digilent' then we perform a Control Transfer to read a field of the EEPROM, which contains bits that specify which interface(s) should be used as a virtual com port. Depending on the value of the bitfield we either return a high probe score so that our driver remians loaded, or we return 0. If the bitfield indicates that the interface is to be used as a VCP we return 0, which again, should cause OSX to continue looking for a suitable driver.

Keeping the above in mind, I have no idea why our driver would remain loaded for your device if it doesn't specify "Digilent" as the manufacturer and contain the appropriate bitfield setting in the EEPROM.

Thanks,
Michael

[albert]

Hi Michael, thanks for the info!

I noticed both devices appear in system_profiler without unloading the driver. Does that tell you anything?

Both devices have the same Vendor ID:

➜  ~ system_profiler SPUSBDataType | grep Digilent -A 7
                Digilent USB Device:

                  Product ID: 0x6014
                  Vendor ID: 0x0403  (Future Technology Devices International Limited)
                  Version: 9.00
                  Serial Number: 210321A18D4C
                  Speed: Up to 480 Mb/sec
                  Manufacturer: Digilent
                  Location ID: 0x14114000 / 32
                  Current Available (mA): 500
                  Current Required (mA): 0
                  Extra Operating Current (mA): 0

➜  ~ system_profiler SPUSBDataType | grep FTDI -C 5

              Product ID: 0x6010
              Vendor ID: 0x0403  (Future Technology Devices International Limited)
              Version: 7.00
              Speed: Up to 480 Mb/sec
              Manufacturer: FTDI
              Location ID: 0x14120000 / 31
              Current Available (mA): 500
              Current Required (mA): 500
              Extra Operating Current (mA): 0

[malexander]

Hi Albert,

I think they should both show up in the system profiler regardless of which driver is attached. What I do see from your post is that the second device doesn't have "Digilent" as the Manufacturer string so our driver should return a probe score of 0, which would give another driver the opportunity to match.

The following is from Apple's Developer website:
 

Driver Matching

When a nub detects a device, the I/O Kit finds and loads a driver for the nub in three distinct phases, using a subtractive process. In each phase, drivers that are not considered to be likely candidates for a match are subtracted from the total pool of possible candidates until a successful candidate is found.

The matching process proceeds as follows:

    In the class matching step, the I/O Kit narrows the list of potential drivers by eliminating any drivers of the wrong class for the provider service (that is, the nub). For example, all driver objects that descend from a SCSI class can be ruled out when the search is for a USB driver.

    In the passive matching step, the driver’s personality (specified in a driver’s XML information property list) is examined for properties specific to the provider’s family. For example, the personality might specify a particular vendor name.

    In the active matching step, the driver’s probe function is called with reference to the nub it is being matched against. This function allows the driver to communicate with the device and verify that it can in fact drive it. The driver returns a probe score that reflects its ability to drive the device. See Device Probing for more information. During active matching, the I/O Kit loads and probes all candidate drivers, then sorts them in order of highest to lowest probe score.

The I/O Kit then chooses the remaining driver with the highest probe score and starts it. If the driver successfully starts, it is added to the I/O Registry and any remaining driver candidates are discarded. If it does not start successfully, the driver with the next highest probe score is started, and so on. If more than one driver is in the pool of possible candidates, the more generic driver typically loses out to the more specific driver if both claim to be able to drive the device.

The probe function takes as arguments the driver’s provider and a pointer to a probe score. The probe score is a signed 32-bit integer initialized to a value specified in the driver’s personality (or to zero if not explicitly initialized). The driver with the highest initial probe score is given the first chance to start operating the device. The purpose of the probe function is to offer drivers an opportunity to check the hardware and to modify their default probe scores as assigned in their personalities. A driver can check device-specific registers or attempt certain operations, adjusting its probe score up or down based on how well suited it is for the device it is examining. Whatever it finds, each driver must leave the hardware in the same state it was in when probe was invoked so the next driver can probe the hardware in its original state.

A driver, in its probe function, returns a driver object (IOService *) if the probe was successful and returns zero otherwise. The returned object is usually the driver itself, but the driver can return another driver that is more suited to the provider. The probe score is an in-out parameter, which probe can modify based on what it discovers about the device.

The probe function takes as arguments the driver’s provider and a pointer to a probe score. The probe score is a signed 32-bit integer initialized to a value specified in the driver’s personality (or to zero if not explicitly initialized). The driver with the highest initial probe score is given the first chance to start operating the device. The purpose of the probe function is to offer drivers an opportunity to check the hardware and to modify their default probe scores as assigned in their personalities. A driver can check device-specific registers or attempt certain operations, adjusting its probe score up or down based on how well suited it is for the device it is examining. Whatever it finds, each driver must leave the hardware in the same state it was in when probe was invoked so the next driver can probe the hardware in its original state.

Driver Loading
A driver, in its probe function, returns a driver object (IOService *) if the probe was successful and returns zero otherwise. The returned object is usually the driver itself, but the driver can return another driver that is more suited to the provider. The probe score is an in-out parameter, which probe can modify based on what it discovers about the device.

Based on the above description and a review of the source code for our driver I believe we are doing the correct thing.

Can you please try disconnecting all FTDI devices, then connecting your USB serial device and executing "syslog | grep Digilent" in the terminal and then paste the results here?

Thanks,

Michael

[albert]

Hi! I tried what you proposed - no output as expected:

➜  cert syslog | grep Digilent
NOTE:  Most system logs have moved to a new logging system.  See log(1) for more information.

However, the output is the same also after attaching the Analog Discovery 2?

[malexander]

Hmm which version of OSX are you running?

[albert]

I'm running Sierra 10.12.4 on a new 15" MacBook Pro (the new touch bar model)

[jpeyron]

Hi @albert, 

Sorry for the delayed response. We are now able to duplicate your Laptop's behavior. We are going to have to do some experimentation to get a fix.

cheers,

Jon

[albert]

That's good bad news..

Thanks for the update!

[albert]

Hi, just checking in - any progress on this?

[albert]

Hi! Very late, but I finally got around to bringing my device to work to test the new driver.. It works fine now, thanks!

[jpeyron]

Hi @albert,

Glad to hear the new driver fixed the issue for you.

Thank you,

Jon