Re: Hybrid CDC + DFU device and libusb
Locked
 
|
Thanks Xiaofan for pointing out the libusb mailinglist. Thanks to Fernando for pointing out the IOService.app. This is the structure I am getting for my device:
AppleACPIPlatformExpert > PCI0@0 > AppleACPIPCI > EHC1@1D,7 > AppleUSBEHCI > Black Magic Probe@fd120000 > AppleUSBCDC > Black Magic Firmware Upgrade@4 > Black Magic GDB Server@0 > AppleUSBCDCACMControl > Black Magic UART Port@2 > AppleUSBCDCACMControl > IOUSBInterface@1 > AppleUSBCDCACMData > IOUSBInterface@3 > AppleUSBCDCACMData Also you asked which version of Mac OS I am running: 10.7.2 Based on the output of IOService it seems that AppleUSBCDC driver is claiming the "Black Magic Probe" device and that may be the reason why libusb can not access the ep0 to read out device strings nor send the detach command to the "Black Magic Firmware Upgrade" DFU Interface (it uses ep0 only not a separate endpoint). Please correct me if I am wrong. I am using pyusb with libusb 1.0 to access the device. The full code can be found here: https://github.com/esden/blackmagic/blob/master/scripts/stm32_mem.py and here https://github.com/esden/blackmagic/blob/master/scripts/dfu.py The error I am getting when running this code is the following: Traceback (most recent call last): File "../scripts/stm32_mem.py", line 75, in <module> man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/legacy.py", line 272, in getString return util.get_string(self.dev, length, index, langid).encode('ascii') File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/util.py", line 248, in get_string 0 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/control.py", line 169, in get_descriptor data_or_wLength = desc_size File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/core.py", line 678, in ctrl_transfer self.__get_timeout(timeout) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/_debug.py", line 52, in do_trace return f(*args, **named_args) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/backend/libusb10.py", line 548, in ctrl_transfer timeout)) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/usb/backend/libusb10.py", line 357, in _check raise USBError(_str_error[retval.value]) usb.core.USBError: Unknown error I hope it will be possible to find some solution to that. Thanks for your help. Cheers Esden On Jan 18, 2012, at 6:37 AM, Xiaofan Chen wrote: > On Wed, Jan 18, 2012 at 4:39 PM, Piotr Esden-Tempski <[hidden email]> wrote: >> I am having an issue with a device that is providing a hybrid device >> with two CDC interfaces and a DFU interface. When plugged in the >> CDC interfaces are being properly detected and presented as two >> /dev/cu.usbmodemxxx. >> >> I am trying to access the remaining DFU interface using libusb, I >> can open and claim the DFU interface but I can't send any commands >> to the device, like get vendor string, get manufacturer string or >> DFU detach command. > > You might be able to get better help in libusb mailing list. > http://www.libusb.org/wiki/MailingList > > You may also want to post your libusb codes snippet. > As answered by Fernando, the get vendor string and > get manufacturer string command should be directed > to the device and not the interface. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
signature.asc (210 bytes)
|
|
|
|
|
|
|
|
|
Hi,
Thanks for your pointers guys. Maybe I can clarify my goal here. The Black Magic probe when connected should at all times automatically load the CDC drivers for it's two serial interfaces. Still although those are loaded it should be possible to access the remaining third DFU interface using libusb. So writing a blank driver that forces the CDC driver to not load is not really a solution because I actually do want the CDC driver to load. Of course I could unload the CDC driver every time I want to access the DFU interface, it is a solution but not a pretty one. As Black Magic Probe is exposed to the OS as a CDC device and the CDC driver is loading for the _device_ itself and then also loads the CDCACMData and CDCACMControl drivers for the interfaces. I can unload the CDCACM interface drivers and although the /dev/cu.usbmodemxxx devices disappear I still can not use the DFU interface. I really have to unload the CDC driver that is loaded for the interface to be able to access the DFU interface. I also investigated in a bit different direction and tried to expose the device to the OS as a Composite device instead of a CDC device. According to Apple USB Device Overview (http://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/USBBook/USBOverview/USBOverview.html) it is possible to present the device to the OS as a composite device by setting the bDeviceClass and bDeviceSubClass to 0. I did that and the AppleUSBComposite is loading. I also get the following messages in dmesg: 0 2 AppleUSBCDCACMControl: start - Failed to find the CDC driver 0 3 AppleUSBCDCECMData: start - Find CDC driver for ECM data interface failed 0 3 AppleUSBCDCACMData: start - Find CDC driver for ACM data interface failed So Mac OS is trying to do the right thing and load the CDC drivers for the CDC interfaces but sadly it fails because it is not finding the core CDC driver. Another datapoint I got is that if the Composite driver is loaded for the device then it is still possible to access the DFU interface. It would be nice to see if it still works after the Composite driver manages to load the CDCACM drivers for the interfaces. Cheers Esden On Jan 19, 2012, at 10:38 AM, Nathan Hjelm wrote: > In the case if MacOS a driver (both interface and device) can effectively claim Ep0 by opening and holding onto a device (ignoring USBDeviceOpenSeize). I can't remember if any of the CDC drivers do this. Just in case the user should probably write a blank interface/device driver to keep any of the OSs drivers from loading. > > -Nathan > > On Jan 19, 2012, at 11:17 AM, Tim Roberts <[hidden email]> wrote: > >> Nathan Hjelm wrote: >> > Opps, I misunderstood what you were trying to accomplish. >> > >> > Is Ep0 or the device claimed by any other driver? >> >> Drivers do not claim endpoints. Only interfaces. Endpoint 0 does not >> belong to any interface. On Linux, at least, endpoint 0 is available >> even if another driver has claimed some of the interfaces. I don't know >> the MacOS rules. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
In reply to this post by Piotr Esden-Tempski
Piotr Esden-Tempski wrote:
> According to Apple USB Device Overview > (http://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/USBBook/USBOverview/USBOverview.html) > it is possible to present the device to the OS as a composite > device by setting the bDeviceClass and bDeviceSubClass to 0. > I did that and the AppleUSBComposite is loading. This is the right approach when you have interfaces which belong to different device classes. (CDC vs. DFU) > I also get the following messages in dmesg: > > 0 2 AppleUSBCDCACMControl: start - Failed to find the CDC driver > 0 3 AppleUSBCDCECMData: start - Find CDC driver for ECM data interface failed > 0 3 AppleUSBCDCACMData: start - Find CDC driver for ACM data interface failed > > So Mac OS is trying to do the right thing and load the CDC drivers > for the CDC interfaces but sadly it fails because it is not finding > the core CDC driver. Investigate why. Note that the Mac OS X kernel is rather picky about descriptors. Quite likely the problem is with the descriptors. I would suggest using Linux and a BSD in order to get more opinion about the descriptors you are using. You can enable kernel USB debugging to get very detailed output. //Peter ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Loading...
| Powered by Nabble | Edit this page |