We have had hundreds of clients install this driver successfully, but in three cases the installation has failed, despite reinstallation. I have observed these reinstallations myself via Skype. These clients have several things in common:
1) They are using OS X. The most recent client is using OS 10.10.4.
2) Reinstallation does not help (even when attempting to uninstall first).
3) The drivers do not show up in the /System/Library/Extensions folder (my own functional installation shows two SiLabs files there).
4) One driver (SiLablsUSBDriver.kext) shows up in the /Library/Extensions folder.
I have been unable to find a way to get these to work. Can someone help me to figure out what is going on? None of these three are able to use the driver with the software interface for our product.
Any help would be much appreciated.
The correct place for CP210x support is under the "Interface" category.
The older driver (pre-Yosemite) puts both a standard and 64 bit version of the kext into /System/Library/Extensions folder. With the new strict restrictions on Yosemite, Apple requires driver signature with drivers placed into /Library/Extensions, which is their preferred location moving forwards. I updated the driver installer to be smart enough to install the correct version (64 vs 32 bit) based on the OS.
My development thread here
has some commands you can try for testing - the development driver was called SiLabsUSBDriverYos.kext, but the released version is SiLabsUSBDriver.kext.
Have your users unplug your device, then try in a Terminal window:
#Verify code signature codesign -vvvvd /Library/Extensions/SiLabsUSBDriver.kext #Verify ownership = root:wheel and permissions = rwxr-xr-x and loadable kextutil -tn /Library/Extensions/SiLabsUSBDriver.kext #unload the driver sudo kextunload SiLabsUSBDriver.kext #Reload the driver sudo kextload -v 6 SiLabsUSBDriver.kext
Now have them plug in the device
#Make sure the driver loaded kextstat #Check for any error messages tail -n 50 /var/log/system.log
Make sure your device shows up in the USB device tree - it will show up even if the driver is not there. The tree is at Apple -> About this Mac -> System Report -> Hardware -> USB
Also check for any hubs they might be using, and see if it works on a different port. Make sure they are using a powered hub if your device requests more than 100 mA current. The Device Tree will report the requested current and the available current.
They shouldn't need to reboot after the install, touching a file in /Library/Extensions forces a kext rebuild automatically.
What exactly is the failure mechanism you/they are seeing? Is it during the install or after? I assume you have other clients that are using 10.10.4 without issue?
Also, is the device using the standard SiLabs VID/PID, or a custom VID/PID? Custom VID/PIDs require SiLabs updating the driver and releasing a new version, due to the strict Apple Gatekeeper requirements. If that's the case, we will need a formal request filed from the manufacturer of the device via Salesforce to get it added to the pList in the driver. If you don't have contacts there, we can try initiating something from our FAEs.
For Windows devices, Microsoft allows for a pass-through certificate, so manufacturers can use our AN721 to customize the Windows driver:
Thanks so much for all the information. I hope to work with one of the clients having trouble tomorrow. For now, here is what I can tell you:
1) The VID/PID is 10C4/EA60. I don't know if you would consider this the standard SiLabs VID/PID or not.
2) My own installation is on a OS 10.10.4 system, but I probably installed the driver last year, so maybe it's old.
3) Generally the installation gives no indication of failure, but the SiLabs ID /dev/tty.SLAB_USBtoUART does not show up in the application's list of ports like it would normally.
Will get you more information soon.
Yes, 10C4/EA60 is our standard VID/PID for our CP210x single-interface devices.
Someone here locally had a 10.10 system running the old driver as well, and was able to uninstall it and install the new driver without issue.
Can you clarify if the hundreds of other installations you have are all on 10.10, or are they a mixture of systems, including Windows? I'd like to get a feel for how often this failure mode is occurring for your customers.
Have you run through the normal USB debug process - removing any hubs, trying other ports, trying other PCs?
Hmmm... Uhhh... Welllll....
So I've seen this four times. One of the people returned her product, so I can't test it. Two of them are so far back that I don't remember them. I just remember that it was installing very differently from my own installation and that the symptoms were always the same. You've since explained that these "symptoms" are simply reflecting the updated installation procedure.
Yesterday, I was able to work with the fourth user and troubleshoot his system remotely. After using some of the checks you provided, I finally realized that it was just a physical connection problem (USB cable not inserted fully) and after we fixed that, the driver worked perfectly.
If I get another user with this problem I will check the physical connection first (I usually do that, anyway), but at least if other problems continue, I will have some tools to figure things out. Thanks for everything you've taught me on troubleshooting this. My apologies for the false alarm.
No worries, it happens all the time. Once had a engineer claim his Tektronix O-scope had a faulty set of digital inputs, I walked up and tried the connector, could tell it was loose, and pushing it in all the way resolved the issue. What had happened is that the detentes for the digital probes "clicked" once when it went past the plastic sheath of the receptacle, and were "close enough" that they were glitchy. It was only when I pushed it all the way in, and heard the hard detente SNAP into place that we knew what happened.
And yes, we ribbed him mercilessly for months over that, although really it was an issue with the probe design.