Swapnil Kulkarni | 4 Sep 13:35 2015

How to use libusb for CDC devices


I am new to libusb and not even very much experienced with USB.
I have a written a firmware for LPC1768 to use it as USB CDC device.
It is getting detected as COM port when I use the driver provided by NXP.
But the problem is when I toggle RTS from any terminal software, host is not generating any request to device. Request is generating only for DTR.

So, I thought to use libusb. I used the inf generator.
When I installed the driver, it is showing as libusb-win32 device.
Can someone tell me how can I configure it as COM port. I want to use it throught terminal software.

Also, will libusb solve my problem with RTS toggling?

Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
张华 | 19 Aug 05:43 2015

How to uninstall the libusbk driver using an unistaller


I've created my driver installer using libusbK-inf-wizard. So I can invoke the generated "InstallDriver.exe" from my application installer to install my drivers. But how to uninstall the drivers using my application installer? Can "InstallDriver.exe" accept some switch like dpinst.exe, such as '/u' to uninstall the installed drivers?

BTW, it seems Win10 need new signature mechanism. I wonder if libusbk and the generated driver installer can work well on Win10?

Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
Xiaofan Chen | 14 Aug 15:55 2015

Summary of Digital Certificate and Windows 10

So from the following summary, the DigiCert that Travis is using
now will still be good until it expires in  21-June-2017.

Post 131.




On Thu, Aug 13, 2015 at 5:26 AM,  <PeterGV <at> osr.com> wrote:
Let me try to restate the rules (this is what we're planning to
publish in The NT Insider... so if it's wrong, I'd appreciate folks
letting me know):

1)       A driver signed with the standard SHA-1 certificate issued
prior to the 29th of July and correctly cross-signed according to the
pre-Windows 10 KMCS procedures, will work on all platforms Vista
through to 10.  This is, however, subject to configurable an
enterprise-defined code integrity policy that is part of Device Guard
(available on Windows 10 Enterprise edition only).  This
enterprise-defined policy may be configured to require at least an
attestation-signed driver.

2)       A driver signed with an EV certificate issued prior to the
29th of July, and cross-signed according to the pre-Windows 10 KMCS
procedure, will work on 8 and above, and will work on Windows 7 /
Server 2008R2 if the patch issued through Windows Update earlier this
year has been applied. It won't work on Vista / Server 2008 though.

3)       A driver signed with any certificate issued after the 29th of
July won't work on Windows 10, unless the driver is signed with a
Microsoft signature available through the SysDev portal.

4)       A portal-signed driver using attestation signing (which
requires an EV certificate) will only work on Windows 10, unless also
signed with an additional valid certificate and cross-signed according
to the pre-Windows 10 KMCS procedure.

5)       A portal-signed driver that passes WLK tests (which requires
an EV certificate) will work on Windows 7 through Windows 10.

6)       Windows Server vNext will only load portal-signed drivers
that have successfully passed the WLK tests.

  <at> OSRDrivers

michel | 6 Aug 22:39 2015

Libusbk for Window 10 signing

if i  get it right today libusbk driver should work fine with win-10 as part
of MS migration plan
old signed driver signed  before win10 will pass win10 signing check .

Does anybodies here has any plan or could get a rebuilt libusbk driver
resigned for win 10 ?
i  can of understand they migth be a 90 day periof where this could be done
but  what  passed  that  fatal 90 day period ?  


View this message in context: http://libusb.6.n5.nabble.com/Libusbk-for-Window-10-signing-tp5714964.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

Xiaofan Chen | 5 Aug 15:35 2015

libusb-win32 source repo mirrored in github

Just for your information, I have created a github mirror of the
libusb-win32 subversion. It is much easier to use github to
look into the commit history than using Sourceforge.

In any case, if someone wants to create a fork of libusb-win32,
please take note of the license. It is more restrictive than libusbK.




licedey | 4 Aug 10:06 2015

libusb_control_transfer returns LIBUSB_ERROR_IO and GetLastError()=1186 (Win7)


I am trying to send Output Report to USB keyboard device using
libusb_control_transfer. After the call I've got such error from libusb
[ 0.157009] [00001c3c] libusb: debug [_hid_set_report] report ID: 0x00
[ 0.157009] [00001c3c] libusb: debug [_hid_set_report] Failed to Write HID
t Report: [1] Incorrect function
Control Out error  - Input/Output Error (LIBUSB_ERROR_IO) (Last error -

And here is my code:

int UsbKeyboardTest()
	auto kbdev = FindKeyboard();
	int r;
	libusb_device_handle *devh = nullptr;
	if ((r = libusb_open(kbdev, &devh)) < 0)
		ShowError("Error open device", r);
		return r;

	r = libusb_set_configuration(devh, 1);
	if (r < 0)
		ShowError("libusb_set_configuration error ", r);
		goto out;
	printf("Successfully set usb configuration 1\n");

	libusb_set_debug(_context, 4);

	r = libusb_claim_interface(devh, 0);
	if (r < 0)
		ShowError("libusb_claim_interface error ", r);
		goto out;

	unsigned char data[8] = { 0 };
	r = libusb_control_transfer(devh, CTRL_OUT,
		0, data, (uint16_t)sizeof(data), 1000);

	if (r < 0) {
		ShowError("Control Out error ", r);
		goto out;
		cout << "Control Transfer send OK - " << r << endl ;


View this message in context: http://libusb.6.n5.nabble.com/libusb-control-transfer-returns-LIBUSB-ERROR-IO-and-GetLastError-1186-Win7-tp5714945.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

Xiaofan Chen | 1 Aug 18:07 2015

Alternative to libusb-win32

Hi all,

I am not so sure how many people are still using libusb-win32. I will
still be able to spend time on this mailing list to support technical
questions but I do not think any new release will be done. It is quite
mature and I think people can still use it (I have not tested Windows
10 yet).

For the libusb-win32 driver portion, other than some legacy device,
I think it is probably better to use WinUSB whenever possible. As
for libusb-win32 library portion (extended libusb-0.1 API), it is probably
better to migrated to libusb-1.0 API (by libusb project). The only missing
function for libusb Windows is currently the isochronous transfer which
I believe will eventually be incorporated.

So I guess if you are happy with libusb-win32 you can continue to use
it. If not, better start to switch to libusb.



Xiaofan Chen | 1 Aug 17:59 2015

libusbK Google Code repo exported to Github

Hi all,

Google code will close down soon. I have take the liberty of exported
the libusbK repo to Github.

I am not so sure how many people are still interested in libusbK
driver portion now that WinUSB has gained isochronous transfer
functionality (after Windows 8.1).

I am also not so sure how many people are still interested in
libusbK library (libusbk.dll) since most likely you can use
WinUSB API directly (for Windows) or libusb API (for
cross-platform application).

In any case, the license of libusbK is pretty liberal. You can
easily fork libusbK if you want.


---------- Forwarded message ----------
From: Google Code Exporter <mdb.google-code-export-noreply <at> google.com>
Date: Fri, May 1, 2015 at 5:31 PM
Subject: Google Code project export complete for usb-travis
To: xiaofanc <at> gmail.com


Export to GitHub

Export Complete

The project usb-travis has been successfully exported.

You can now visit your project on GitHub at: github.com/mcuee/usb-travis.

You may wish to enable subscriptions for issue notifications for the
newly created repo. If so, visit github.com/watching and click "Stop

If you are a member of the project on Google Code, now would be a good
time to update the project's homepage to indicate it has moved to
GitHub. Alternatively, you can also set the "Project Moved" link to
redirect users to your project's new location. See the FAQ for more

· About Google
· Privacy & Terms

Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
Xiaofan Chen | 30 Jul 16:07 2015

Fwd: [Libusbx-devel] Announcing libusb-1.0.20-rc1

FYI as well.

---------- Forwarded message ----------
From: Chris Dickens <christopher.a.dickens <at> gmail.com>
Date: Thu, Jul 30, 2015 at 1:48 AM
Subject: [Libusbx-devel] Announcing libusb-1.0.20-rc1
To: "libusb-devel <at> lists.sourceforge.net"
<libusb-devel <at> lists.sourceforge.net>, libusbx-devel
<libusbx-devel <at> lists.sourceforge.net>

Hi All,

I'm pleased to announce the libusb-1.0.20-rc1 release.

It has been over a year since the last release, and a lot of changes
have gone in during that time (86 commits).

2015-07-29: v1.0.20
* Add Haiku support
* Fix multiple memory and resource leaks (#16, #52, #76, #81)
* Fix possible deadlock when executing transfer callback
* New libusb_free_pollfds() API
* Darwin: Fix devices not being detected on OS X 10.8 (#48)
* Linux: Allow larger isochronous transfer submission (#23)
* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
* Windows: Fix broken bus number lookup
* Windows: Improve submission of control requests for composite devices
* Improve efficiency of event handling
* Improve speed of transfer submission in multi-threaded environments
* Various other bug fixes and improvements
The (#xx) numbers are libusb issue numbers, see ie:

You can download the 1.0.20-rc1 tarball here:

Please test and let us know if you find any issues. We plan to release
a final version of 1.0.20 in the next 2-3 weeks.


Tim Hutt | 23 Jul 09:12 2015

Missing isochronous packets

I'm trying to transmit 64 byte isochronous USB packets over a USB high speed link from a SAM3X (in an Arduino Due) to a libusbk program (basically the example benchmark program it comes with).

I have one isochronous endpoint on the device and it sends data in a tight loop like this (using Atmel's SDK):

uint8_t buffer[UDI_VENDOR_EPS_SIZE_ISO_HS]; // 64 bytes. for (int i = 0; i < sizeof(buffer); ++i) buffer[i] = i; for (;;) { led = !led; udi_vendor_iso_in_run(buffer, sizeof(buffer), nullptr); // TODO: How to wait until it is finished? buffer[0]++; if (buffer[0] == 0) buffer[1]++; }

The receiving program is basically the example iso read program from libusbk. It writes data to a log file, including the first two bytes of each packet which I increment as shown above. It requests 128 packets per frame, and outputs data like this:

#6: StartFrame=00DDE360h LastFrameCount=16 TransferLength=8192 BPS-average:390409.30 #0000: Length=64 C0h 3Dh #0001: Length=64 E1h 3Dh #0002: Length=64 01h 3Eh #0003: Length=64 23h 3Eh #0004: Length=64 44h 3Eh #0005: Length=64 64h 3Eh #0006: Length=64 85h 3Eh #0007: Length=64 A6h 3Eh #0008: Length=64 C7h 3Eh ... snip ... #0120: Length=64 34h 4Dh #0121: Length=64 55h 4Dh #0122: Length=64 76h 4Dh #0123: Length=64 97h 4Dh #0124: Length=64 B8h 4Dh #0125: Length=64 D9h 4Dh #0126: Length=64 FAh 4Dh #0127: Length=64 1Bh 4Eh

As you can see, it works but is skipping loads of the packets. I'd like to know why! The data rate is really low compared to what USB 2 can do. I'm kind of at a loss here as I don't know how to wait until a transfer is completed in a tight loop on the SAM3X. Also... it should work right?

Here are the USB descriptors (I snipped some unused endpoints):

Device Power State: PowerDeviceD0 ---===>Device Information<===--- English product name: "" ConnectionStatus: Current Config Value: 0x01 -> Device Bus Speed: High Device Address: 0x05 Open Pipes: 0 *!*ERROR: No open pipes! ===>Device Descriptor<=== bLength: 0x12 bDescriptorType: 0x01 bcdUSB: 0x0200 bDeviceClass: 0x00 -> This is an Interface Class Defined Device bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 = (64) Bytes idVendor: 0x1111 = Dade Behring, Inc. // Screw the USB-IF! idProduct: 0x2223 bcdDevice: 0x0100 iManufacturer: 0x01 English (United States) "" iProduct: 0x02 English (United States) "" iSerialNumber: 0x00 bNumConfigurations: 0x01 ---===>Full Configuration Descriptor<===--- ===>Configuration Descriptor<=== bLength: 0x09 bDescriptorType: 0x02 wTotalLength: 0x0045 -> Validated bNumInterfaces: 0x01 bConfigurationValue: 0x01 iConfiguration: 0x00 bmAttributes: 0x80 -> Bus Powered MaxPower: 0x32 = 100 mA ===>Interface Descriptor<=== bLength: 0x09 bDescriptorType: 0x04 bInterfaceNumber: 0x00 bAlternateSetting: 0x00 bNumEndpoints: 0x00 bInterfaceClass: 0xFF -> Interface Class Unknown to USBView bInterfaceSubClass: 0xFF bInterfaceProtocol: 0xFF iInterface: 0x00 ===>Interface Descriptor<=== bLength: 0x09 bDescriptorType: 0x04 bInterfaceNumber: 0x00 bAlternateSetting: 0x01 bNumEndpoints: 0x06 bInterfaceClass: 0xFF -> Interface Class Unknown to USBView bInterfaceSubClass: 0xFF bInterfaceProtocol: 0xFF iInterface: 0x00
(snipped irrelevant endpoints) ===>Endpoint Descriptor<=== <---- This is the endpoint I'm using. bLength: 0x07 bDescriptorType: 0x05 bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1 bmAttributes: 0x01 -> Isochronous Transfer Type, Synchronization Type = No Synchronization, Usage Type = Data Endpoint wMaxPacketSize: 0x0040 = 1 transactions per microframe, 0x40 max bytes bInterval: 0x01

Does anyone have any ideas?



Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
michel | 13 Jul 09:14 2015

ibusbk claim interface fail after 32 loops

I'm doing a simple repetitive open/close test using libusb 1.0.19 and libusbk

The target device is a composite device based on CDC/ACM  (2 interface MI0
and MI1) type configuration but with vendor specific class code 

basically what i'm doing 

libusb_open(device, &handle);


After 32 loops claim interface will fail with error -3 
this doesn't happen with 3.0.6  thousand loops can be execuetd without any

i'm using win-7 64 

failure occur in both 32/64 bits (mingw32/64) . 

View this message in context: http://libusb.6.n5.nabble.com/ibusbk-claim-interface-fail-after-32-loops-tp5714845.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.