mchelper crashing in Mac OS X 10.5 (Leopard)

[mechgyver]

The mchelper application crashes when trying to upload firmware to the Make Controller in Mac OS X 10.5 (Leopard).

I tried building mchelper from source using XCode in Leopard I still get the same result.

There is a message thread in the Forum regarding this problem, so I know that it is not isolated to my computer.

I'll happily supply as much information as is needed to fix this problem if this description is not sufficient.

Thanks!

[billnapier]

Here's what I've found on this so far, but I'm at a bit of a loss as to how to fix it.

One of the USB calls (I think USBOpenDevice) returns kIOReturnExclusiveAccess. My guess is that Leopard ships with some kind of driver that claims this USB devices, so when mchelper tries to open it it fails.

The solution I found on a mailing list was to install a codeless KEXT that prevents the other driver from claming it. I found an example of one here: http://lists.apple.com/archives/usb/2007/Dec/msg00001.html

But I couldn't get it to actually fix the problem...

[liamMT]

Yep - this is exactly the problem, although this is not expected behavior for the Apple USB driver. Even using the USB Prober application, the device responds with a kIOReturnExclusiveAccess so that's not a good thing. Ideally we won't need to install a codeless kext.

I've been back and forth a bit with one of the Apple USB developers about it and he's confirmed that there's something fishy going on, but haven't heard back with anything definitive yet. Will definitely post here once I do.

Replying to billnapier:

Here's what I've found on this so far, but I'm at a bit of a loss as to how to fix it. One of the USB calls (I think USBOpenDevice) returns kIOReturnExclusiveAccess. My guess is that Leopard ships with some kind of driver that claims this USB devices, so when mchelper tries to open it it fails. The solution I found on a mailing list was to install a codeless KEXT that prevents the other driver from claming it. I found an example of one here: http://lists.apple.com/archives/usb/2007/Dec/msg00001.html But I couldn't get it to actually fix the problem...

[liamMT]

Uh oh. This response back from Apple:

"After looking at this some more the device functional descriptors are indeed incorrect, so the control driver bails, and the data driver can't survive without the control driver which sends the modem set up and tear down commands. The Call Management functional descriptor indicates it does not do call management on the data channel or call management at all (I.E. we can't send AT commands to the device). How this worked on Tiger is beyond me as the enumeration portion of the driver, where this gets checked, has not changed in a number of years.

The correct solution to the problem is to get Atmel to fix the descriptor. It's currently 0x05 0x24 0x01 0x00 0x01 and it should be 0x05 0x24 0x01 0x03 0x01. I know this is a tall order as there's probably lots of these "bad" devices in the field but is the correct solution.

In the meantime I'll see if my management will let me relax the call management check.

Sorry not the answer you wanted..."

We'll see what happens with this, but in the meantime we might need to get that codeless kext working...

[liamMT]

In fact, the codeless kext is not a viable solution because once it's installed, we'd need to install our own driver for the board since it would no longer be using the built-in Apple driver.

[liamMT]

I think we'll just need to organize it so that we don't crash when the upload fails (duh), but just return a message saying that the upload failed. Then once Apple releases a good driver we'll be all set. This is all I'll resolve to do before releasing.

[liamMT]

This is now done. I'm closing this ticket since the crashes are no longer happening. I've opened #50 to keep a place holder for this issue, however.

[anonymous]

Milestone mchelper 2.1 deleted