I have a simple piece of code that sends a USB command a gets a response. The problem is that it will send it the first time, and get the response, but the second time the code is executed it does not. This issue has only shown up when the platform is El Capitan. It works fine on Yosemite-based computers. I assume this is related to the rewrite of the USB-stack that occurred for El Capitan.
I’ve tried looking for error states, blah, blah, blah, but to no avail. It appears subsequent commands get stuck somewhere. I can’t tell the users to downgrade. Any net.wisdom is highly appreciated.
Here’s the snippet, but again, it does work on Yosemite.
sendBuffer.Command = Command
sendBuffer.Length = 0
Log "Write to sensor: " + Str(EncodeHex(sendbuffer.StringValue(False)))
SensorUSB.Write(sendBuffer.stringvalue(False))
Log "Last write error " + Str(SensorUSB.LastErrorCode)
SensorUSB.XmitWait
SensorUSB.Poll
timerThread.duration = timeout
timerThread.run
while not gDataAvailable And Not gTimerExpired
SensorUSB.Poll
Wend
if gDataAvailable Then
gDataAvailable = False
Log "Data available."
returnBuffer = SensorUSB.Read(returnBuffer.size)
End If
if gTimerExpired Then
Log "No data received within timeout period of " + str(timeout) + " seconds"
End If
I ended up having to turn System Integrity Protection off to get my USB to serial converter to work in one of my apps in EC. I wonder if that will help you too.
You’ll have to boot up in recovery mode (cmd R at startup) and then do this in the terminal: csrutil disable. Then restart normally.
[quote=222674:@Bob Keeney]I ended up having to turn System Integrity Protection off to get my USB to serial converter to work in one of my apps in EC. I wonder if that will help you too.
You’ll have to boot up in recovery mode (cmd R at startup) and then do this in the terminal: csrutil disable. Then restart normally.[/quote]
This basically is up to the driver and I really wish hardware vendors cared more about OS X.
I have worked on this for two months with no joy. It works fine in Yosemite, even in a virtual machine. Short of some kind of USB reset at the OS level. I’m still stumped.
I am working on a long time project that uses the serial port, my only solution after a week of wasting a lot of time was to revert my machine back to Yosemite, there appears currently to be no other option, without turning off SIP, and that is completely unsatisfactory in the real world I find.
Having said that Yosemite works perfectly well in all aspects for me so it will be a long time until I am forced to find an alternative.
This is not really an Apple problem. El Capitan enforces kext driver signing. Have you checked the vendor for a later driver that is signed?
If this is a USB to serial adapter, it is probably made by Prolific (I find the PL2303 is the most common) , and they have 64 bit signed drivers now: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41
USB stuff is SO hosed on El Capitan. I am having similar problems with things. I will start recommending to people to put their adaptors on hubs if they arent already and see if that solves it for anyone, but Im a little dubious. I will test this afternoon with some FTDI devices I use.
Its not just serial devices either, Ive got a USB audio adaptor that I use and it just stops working once a day or so. I moved it to a hub to be easier to unplug and replug it to get the music going again. That has been happening since the first version of El Capitan.
I had the FTDI drivers stop recognizing the adaptor here just yesterday even after installing the latest version of them, turning off SIP and rebooting. I pulled the adaptor out and it never actually went away from the system profiler output. If I plugged it back in then I would get 2 entries in the USB device list, but it wouldnt show up in the available list in any program.
Ive got a user who has 2 such adaptors and whenever he quite my xojo program it causes the other program connected to a totally separate USB interface but by the same company, to disconnect and refuse to reconnect as well. So you can crash things that youre not even really connected to.
My system log just scrolls constantly with these sorts of messages, tens of thousands of them:
1/21/16 1:32:41.989 PM system_profiler[55742]: SPUSBDevice: IOServiceGetMatchingService did not return anything for location 0x00210000
1/21/16 1:32:41.989 PM system_profiler[55742]: SPUSBDevice: IOServiceGetMatchingService did not return anything for location 0x00240000
1/21/16 1:32:41.989 PM system_profiler[55742]: SPUSBDevice: IOServiceGetMatchingService did not return anything for location 0x00200000
Were on what, the third build of 10.11 now? And this is still completely hosed. Sorry, no useful info Just venting and expressing my solidarity for your situation.
It doesn’t make any difference if the device is on a hub. I’ve tried a few.
I have tried disabling the signing requirement of the kext with SIP, while leaving all other protections intact. That didn’t work. I now believe the problem is between the serial control of Xojo and El Capitan. Once you write to it, you can’t write to it again in my environment. I’ve tried waits, flushes, all kinds of things. The only thing that works is to disconnect the device and reconnect. Then I get one send through.
This is an Atmel device; they are no help at all. I tried to use the MBS plug-in, too, but since the standard driver gets loaded when the device enumerates the MBS plug-in always reports a busy.
Ive had the problem with the FTDI drivers disappearing until I reboot with the Arduino IDE which is written in java, so its not just Xojo that is suffering. That isnt to say that both Java and Xojo dont get it wrong together though.
Just venting and expressing my solidarity for your situation.