libusb-win32-devel

[Libusb-win32-devel] usb_control_msg works in linux but not windows

[Rob W. <ro...@sa...>]

Good day...

We are writing some proof of concept software to ensure a new USB device 
will be usable in both Linux and Windows.

The following line turns on an LED.

     int t2 = usb_control_msg(handle, 0x01, 10, on   , 0, 0, 0, 10);

and works just fine in Linux, however produces the following error in 
Windows:

     libusb0-dll:err [control_msg] sending control message failed, win 
error: The parameter is incorrect.

I am very new to USB, and have not been able to find any kind of 
reference as to why it would work on one side, but not the other... Any 
help would be most appreciated.

Rob

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Xiaofan C. <xia...@gm...>]

On Thu, Feb 20, 2014 at 7:23 AM, Rob Willard <ro...@sa...> wrote:
> Good day...
>
> We are writing some proof of concept software to ensure a new USB device
> will be usable in both Linux and Windows.
>
> The following line turns on an LED.
>
>      int t2 = usb_control_msg(handle, 0x01, 10, on   , 0, 0, 0, 10);
>
> and works just fine in Linux, however produces the following error in
> Windows:
>
>      libusb0-dll:err [control_msg] sending control message failed, win
> error: The parameter is incorrect.
>
> I am very new to USB, and have not been able to find any kind of
> reference as to why it would work on one side, but not the other... Any
> help would be most appreciated.
>

You can try to install debug version of libusb-win32 and
then run your program. Then you can post the debug
message using Debug View.

Debug version of libusb-win32:
http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/
 File name: libusb-win32-bin-debug-1.2.6.0.zip

Microsoft DebugView
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

Detail steps:
1) unzip libusb-win32-bin-debug-1.2.6.0.zip

2) Depending on you OS:
2a) 64bit PCs Only: copy 'bin\amd64\libusb0.sys' to
'windows\system32\drivers\libusb0.sys', disconnect your USB device and
re-boot.

2b) 32bit PCs Only: copy 'bin\x86\libusb0.sys' to
'windows\system32\drivers\libusb0.sys', disconnect your USB device and
re-boot.

3) Launch DbgView (you MUST right click and run as administrator)

4) Under the capture menu, ensure all items are checked

5) Connect your device and then run your program

6) messages should appear in DebugView. Save the
log and post it.



-- 
Xiaofan

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Travis <lib...@gm...>]

Greetings,

You are trying to use a "standard" usb request for what should be a 
vendor request type. IE: the 0x01 in the 2nd param.

For the 2nd param (request type) you need to use something like the 
following to perform an action like that:
requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
or
requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT

if you specify USB_ENDPOINT_IN then you are saying you want the "bytes" 
portion to be returned from the device (DEVICE TO HOST)
if you specify USB_ENDPOINT_OUT then you are saying you want the "bytes" 
portion to be sent to the device (HOST TO DEVICE)

Regards,
Travis

On 2/19/2014 4:23 PM, Rob Willard wrote:
> Good day...
>
> We are writing some proof of concept software to ensure a new USB device
> will be usable in both Linux and Windows.
>
> The following line turns on an LED.
>
>       int t2 = usb_control_msg(handle, 0x01, 10, on   , 0, 0, 0, 10);
>
> and works just fine in Linux, however produces the following error in
> Windows:
>
>       libusb0-dll:err [control_msg] sending control message failed, win
> error: The parameter is incorrect.
>
> I am very new to USB, and have not been able to find any kind of
> reference as to why it would work on one side, but not the other... Any
> help would be most appreciated.
>
> Rob
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Xiaofan C. <xia...@gm...>]

On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
> Greetings,
>
> You are trying to use a "standard" usb request for what should be a
> vendor request type. IE: the 0x01 in the 2nd param.
>
> For the 2nd param (request type) you need to use something like the
> following to perform an action like that:
> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
> or
> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>
> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
> portion to be returned from the device (DEVICE TO HOST)
> if you specify USB_ENDPOINT_OUT then you are saying you want the "bytes"
> portion to be sent to the device (HOST TO DEVICE)
>

Good analysis.

To the OP, if you are new to USB, you may want to go
through the following short introduction to USB.
http://www.usbmadesimple.co.uk/index.html

In particular, the following section talks about some of
the terminology used in the above.
http://www.usbmadesimple.co.uk/ums_4.htm

A bit more in detail
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx

If you want to read more,then the USB 2.0 spec is the best.

-- 
Xiaofan

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Rob W. <ro...@sa...>]

Thanks for the responses!

I have read up more, and still have the same type of issues. I have 
revisited my request type:

     usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1, 
0, 0, buff, 64, 10);

however still recieve errors in Windows (**this works fine under linux 
using usb.h). Should return a string, but am getting:

     libusb0-dll:err [control_msg] sending control message failed, win 
error: A device attached to the system is not functioning.

I did as Xiaofan suggested and loaded the debug version. The output is 
attached.

Any further direction would be most appreciated...

Rob


On 14-02-19 07:52 PM, Xiaofan Chen wrote:
> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>> Greetings,
>>
>> You are trying to use a "standard" usb request for what should be a
>> vendor request type. IE: the 0x01 in the 2nd param.
>>
>> For the 2nd param (request type) you need to use something like the
>> following to perform an action like that:
>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>> or
>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>
>> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
>> portion to be returned from the device (DEVICE TO HOST)
>> if you specify USB_ENDPOINT_OUT then you are saying you want the "bytes"
>> portion to be sent to the device (HOST TO DEVICE)
>>
> Good analysis.
>
> To the OP, if you are new to USB, you may want to go
> through the following short introduction to USB.
> http://www.usbmadesimple.co.uk/index.html
>
> In particular, the following section talks about some of
> the terminology used in the above.
> http://www.usbmadesimple.co.uk/ums_4.htm
>
> A bit more in detail
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx
>
> If you want to read more,then the USB 2.0 spec is the best.
>

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Travis <lib...@gm...>]

You are still sending a "standard" clear feature request:

00000034	8.28595066	libusb0-sys:[clear_feature] recipient: 01 index: 0000 feature: 0000 timeout: 10	

I again suggest you use a vendor request type and update your firmware 
accordingly.  I'd also increase the timeout to 1s for testing.

That said, it looks like the request is making it to your device now but 
it is your device that is not excepting it. Note that you have changed 
what your device firmware need to look for; did you update your firmware??

If I remember correctly, a "A device attached to the system is not 
functioning." error message after a control request generally means your 
device did not recognize the request and set a STALL condition.

Regards,
Travis

On 2/21/2014 1:33 PM, Rob Willard wrote:
> Thanks for the responses!
>
> I have read up more, and still have the same type of issues. I have 
> revisited my request type:
>
>     usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1, 
> 0, 0, buff, 64, 10);
>
> however still recieve errors in Windows (**this works fine under linux 
> using usb.h). Should return a string, but am getting:
>
>     libusb0-dll:err [control_msg] sending control message failed, win 
> error: A device attached to the system is not functioning.
>
> I did as Xiaofan suggested and loaded the debug version. The output is 
> attached.
>
> Any further direction would be most appreciated...
>
> Rob
>
>
> On 14-02-19 07:52 PM, Xiaofan Chen wrote:
>> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>>> Greetings,
>>>
>>> You are trying to use a "standard" usb request for what should be a
>>> vendor request type. IE: the 0x01 in the 2nd param.
>>>
>>> For the 2nd param (request type) you need to use something like the
>>> following to perform an action like that:
>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>>> or
>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>>
>>> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
>>> portion to be returned from the device (DEVICE TO HOST)
>>> if you specify USB_ENDPOINT_OUT then you are saying you want the 
>>> "bytes"
>>> portion to be sent to the device (HOST TO DEVICE)
>>>
>> Good analysis.
>>
>> To the OP, if you are new to USB, you may want to go
>> through the following short introduction to USB.
>> http://www.usbmadesimple.co.uk/index.html
>>
>> In particular, the following section talks about some of
>> the terminology used in the above.
>> http://www.usbmadesimple.co.uk/ums_4.htm
>>
>> A bit more in detail
>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx 
>>
>>
>> If you want to read more,then the USB 2.0 spec is the best.
>>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Rob W. <ro...@sa...>]

I would concur, and will speak with my firware guy, however this works 
fine in linux, telling me the firmware is fine.

A further example is the following, which turns on an LED in linux:
     int t2 = usb_control_msg(handle, USB_RECIP_INTERFACE | 
USB_ENDPOINT_OUT, 10, on   , 0, 0, 0, 10);
     where on is an int.

receives the following error in Windows:
     libusb0-dll:err [control_msg] sending control message failed, win 
error: The parameter is incorrect.

I do have a packet sniffer in line with the device, and while I see the 
setup commands fine, there is no packet activity on the requests I have 
been speaking to while under Windows...


Here, for reference, is a code snippet that is in the firmware handling 
the requests:

static uint8_t
117    USBD_Class_cb_Setup(void *pdev, USB_SETUP_REQ *req) {
118            DebugOut(" SU %d %d %d", req->bmRequest, req->bRequest, 
req->wValue);
119
120            if (req->bRequest == 11) {
121                    return RequestSamAD(pdev, req);
122            } else if (req->bRequest == 12) {
123                    return UsbHandleMic(pdev, req);
124            } else if (req->bRequest == 14) {
125                    return UsbHandleMult(pdev, req);
126            }
127
128            if (req->bmRequest & 0x80) {
129                    // IN (read string from device)
130                    switch (req->bRequest) {
131                            case 1:
132                                    USBD_CtlSendData(pdev, (unsigned 
char *) banner, strlen(banner) + 1);
133                                    break;
134                            default:
135                                    USBD_CtlSendData(pdev, (unsigned 
char *) "what?", 6);
136                                    break;
137                    }
138            } else if (req->wLength > 0) {
139                    // OUT (write string to device)
140                    USBD_CtlPrepareRx(pdev, ep0recbuff, req->wLength);
141            } else {
142                    // simple integer command
143                    switch (req->bRequest) {
144                            case 10:
145                                    return RequestLight(pdev, req);
146                            default:
147                                    return USBD_FAIL;
148                    }
149            }
150            return USBD_OK;
151    }


Again, very much appreciate the responses I have been getting!
Rob


On 14-02-21 02:04 PM, Travis wrote:
> You are still sending a "standard" clear feature request:
>
> 00000034	8.28595066	libusb0-sys:[clear_feature] recipient: 01 index: 0000 feature: 0000 timeout: 10	
>
> I again suggest you use a vendor request type and update your firmware
> accordingly.  I'd also increase the timeout to 1s for testing.
>
> That said, it looks like the request is making it to your device now but
> it is your device that is not excepting it. Note that you have changed
> what your device firmware need to look for; did you update your firmware??
>
> If I remember correctly, a "A device attached to the system is not
> functioning." error message after a control request generally means your
> device did not recognize the request and set a STALL condition.
>
> Regards,
> Travis
>
> On 2/21/2014 1:33 PM, Rob Willard wrote:
>> Thanks for the responses!
>>
>> I have read up more, and still have the same type of issues. I have
>> revisited my request type:
>>
>>      usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1,
>> 0, 0, buff, 64, 10);
>>
>> however still recieve errors in Windows (**this works fine under linux
>> using usb.h). Should return a string, but am getting:
>>
>>      libusb0-dll:err [control_msg] sending control message failed, win
>> error: A device attached to the system is not functioning.
>>
>> I did as Xiaofan suggested and loaded the debug version. The output is
>> attached.
>>
>> Any further direction would be most appreciated...
>>
>> Rob
>>
>>
>> On 14-02-19 07:52 PM, Xiaofan Chen wrote:
>>> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>>>> Greetings,
>>>>
>>>> You are trying to use a "standard" usb request for what should be a
>>>> vendor request type. IE: the 0x01 in the 2nd param.
>>>>
>>>> For the 2nd param (request type) you need to use something like the
>>>> following to perform an action like that:
>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>>>> or
>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>>>
>>>> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
>>>> portion to be returned from the device (DEVICE TO HOST)
>>>> if you specify USB_ENDPOINT_OUT then you are saying you want the
>>>> "bytes"
>>>> portion to be sent to the device (HOST TO DEVICE)
>>>>
>>> Good analysis.
>>>
>>> To the OP, if you are new to USB, you may want to go
>>> through the following short introduction to USB.
>>> http://www.usbmadesimple.co.uk/index.html
>>>
>>> In particular, the following section talks about some of
>>> the terminology used in the above.
>>> http://www.usbmadesimple.co.uk/ums_4.htm
>>>
>>> A bit more in detail
>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx
>>>
>>>
>>> If you want to read more,then the USB 2.0 spec is the best.
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Rob W. <ro...@sa...>]

Further to what I mentioned about the sniffer. When I send the following:
     usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1, 
0, 0, buff, 64, 10);

via Linux, my sniffer shows the following:
     SETUP txn                81 01 00 00 00 00 40 00
         SETUP packet       2D 01 E8
         DATA0 packet      C3 81 01 00 00 00 00 40 00 57 58
         ACK packet          D2
     IN txn                       6C 69 67 ... (my response string)


When I run the exact same command in Windows, there are no packets sent 
to the device.

Other commands (eg. usb_get_string_simple(handle, 1, buff, 64); retrieve 
the proper strings and I can see the transaction on my sniffer both in 
Windows and Linux.

Rob


On 14-02-21 02:22 PM, Rob Willard wrote:
> I would concur, and will speak with my firware guy, however this works
> fine in linux, telling me the firmware is fine.
>
> A further example is the following, which turns on an LED in linux:
>       int t2 = usb_control_msg(handle, USB_RECIP_INTERFACE |
> USB_ENDPOINT_OUT, 10, on   , 0, 0, 0, 10);
>       where on is an int.
>
> receives the following error in Windows:
>       libusb0-dll:err [control_msg] sending control message failed, win
> error: The parameter is incorrect.
>
> I do have a packet sniffer in line with the device, and while I see the
> setup commands fine, there is no packet activity on the requests I have
> been speaking to while under Windows...
>
>
> Here, for reference, is a code snippet that is in the firmware handling
> the requests:
>
> static uint8_t
> 117    USBD_Class_cb_Setup(void *pdev, USB_SETUP_REQ *req) {
> 118            DebugOut(" SU %d %d %d", req->bmRequest, req->bRequest,
> req->wValue);
> 119
> 120            if (req->bRequest == 11) {
> 121                    return RequestSamAD(pdev, req);
> 122            } else if (req->bRequest == 12) {
> 123                    return UsbHandleMic(pdev, req);
> 124            } else if (req->bRequest == 14) {
> 125                    return UsbHandleMult(pdev, req);
> 126            }
> 127
> 128            if (req->bmRequest & 0x80) {
> 129                    // IN (read string from device)
> 130                    switch (req->bRequest) {
> 131                            case 1:
> 132                                    USBD_CtlSendData(pdev, (unsigned
> char *) banner, strlen(banner) + 1);
> 133                                    break;
> 134                            default:
> 135                                    USBD_CtlSendData(pdev, (unsigned
> char *) "what?", 6);
> 136                                    break;
> 137                    }
> 138            } else if (req->wLength > 0) {
> 139                    // OUT (write string to device)
> 140                    USBD_CtlPrepareRx(pdev, ep0recbuff, req->wLength);
> 141            } else {
> 142                    // simple integer command
> 143                    switch (req->bRequest) {
> 144                            case 10:
> 145                                    return RequestLight(pdev, req);
> 146                            default:
> 147                                    return USBD_FAIL;
> 148                    }
> 149            }
> 150            return USBD_OK;
> 151    }
>
>
> Again, very much appreciate the responses I have been getting!
> Rob
>
>
> On 14-02-21 02:04 PM, Travis wrote:
>> You are still sending a "standard" clear feature request:
>>
>> 00000034	8.28595066	libusb0-sys:[clear_feature] recipient: 01 index: 0000 feature: 0000 timeout: 10	
>>
>> I again suggest you use a vendor request type and update your firmware
>> accordingly.  I'd also increase the timeout to 1s for testing.
>>
>> That said, it looks like the request is making it to your device now but
>> it is your device that is not excepting it. Note that you have changed
>> what your device firmware need to look for; did you update your firmware??
>>
>> If I remember correctly, a "A device attached to the system is not
>> functioning." error message after a control request generally means your
>> device did not recognize the request and set a STALL condition.
>>
>> Regards,
>> Travis
>>
>> On 2/21/2014 1:33 PM, Rob Willard wrote:
>>> Thanks for the responses!
>>>
>>> I have read up more, and still have the same type of issues. I have
>>> revisited my request type:
>>>
>>>       usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1,
>>> 0, 0, buff, 64, 10);
>>>
>>> however still recieve errors in Windows (**this works fine under linux
>>> using usb.h). Should return a string, but am getting:
>>>
>>>       libusb0-dll:err [control_msg] sending control message failed, win
>>> error: A device attached to the system is not functioning.
>>>
>>> I did as Xiaofan suggested and loaded the debug version. The output is
>>> attached.
>>>
>>> Any further direction would be most appreciated...
>>>
>>> Rob
>>>
>>>
>>> On 14-02-19 07:52 PM, Xiaofan Chen wrote:
>>>> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>>>>> Greetings,
>>>>>
>>>>> You are trying to use a "standard" usb request for what should be a
>>>>> vendor request type. IE: the 0x01 in the 2nd param.
>>>>>
>>>>> For the 2nd param (request type) you need to use something like the
>>>>> following to perform an action like that:
>>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>>>>> or
>>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>>>>
>>>>> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
>>>>> portion to be returned from the device (DEVICE TO HOST)
>>>>> if you specify USB_ENDPOINT_OUT then you are saying you want the
>>>>> "bytes"
>>>>> portion to be sent to the device (HOST TO DEVICE)
>>>>>
>>>> Good analysis.
>>>>
>>>> To the OP, if you are new to USB, you may want to go
>>>> through the following short introduction to USB.
>>>> http://www.usbmadesimple.co.uk/index.html
>>>>
>>>> In particular, the following section talks about some of
>>>> the terminology used in the above.
>>>> http://www.usbmadesimple.co.uk/ums_4.htm
>>>>
>>>> A bit more in detail
>>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx
>>>>
>>>>
>>>> If you want to read more,then the USB 2.0 spec is the best.
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>>
>>>
>>> _______________________________________________
>>> Libusb-win32-devel mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Travis <lib...@gm...>]

One more thing,

This request is also invalid for a clear feature request. Clear/set 
feature request are not supposed to pass data in either direction. EG:

VALID:
usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_OUT, 1, 
[Feature], [InterfaceNumber], NULL, 0, 1000);

If you want to pass data to/from the device then you cannot use 
clear/set feature.  These are only meant for setting and clearing 
boolean values. See:
http://www.beyondlogic.org/usbnutshell/usb6.shtml

Regards,
Travis

On 2/21/2014 2:04 PM, Travis wrote:
> You are still sending a "standard" clear feature request:
>
> 00000034    8.28595066    libusb0-sys:[clear_feature] recipient: 01 
> index: 0000 feature: 0000 timeout: 10
>
> I again suggest you use a vendor request type and update your firmware 
> accordingly.  I'd also increase the timeout to 1s for testing.
>
> That said, it looks like the request is making it to your device now 
> but it is your device that is not excepting it. Note that you have 
> changed what your device firmware need to look for; did you update 
> your firmware??
>
> If I remember correctly, a "A device attached to the system is not 
> functioning." error message after a control request generally means 
> your device did not recognize the request and set a STALL condition.
>
> Regards,
> Travis
>
> On 2/21/2014 1:33 PM, Rob Willard wrote:
>> Thanks for the responses!
>>
>> I have read up more, and still have the same type of issues. I have 
>> revisited my request type:
>>
>>     usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1, 
>> 0, 0, buff, 64, 10);
>>
>> however still recieve errors in Windows (**this works fine under 
>> linux using usb.h). Should return a string, but am getting:
>>
>>     libusb0-dll:err [control_msg] sending control message failed, win 
>> error: A device attached to the system is not functioning.
>>
>> I did as Xiaofan suggested and loaded the debug version. The output 
>> is attached.
>>
>> Any further direction would be most appreciated...
>>
>> Rob
>>
>>
>> On 14-02-19 07:52 PM, Xiaofan Chen wrote:
>>> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>>>> Greetings,
>>>>
>>>> You are trying to use a "standard" usb request for what should be a
>>>> vendor request type. IE: the 0x01 in the 2nd param.
>>>>
>>>> For the 2nd param (request type) you need to use something like the
>>>> following to perform an action like that:
>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>>>> or
>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>>>
>>>> if you specify USB_ENDPOINT_IN then you are saying you want the 
>>>> "bytes"
>>>> portion to be returned from the device (DEVICE TO HOST)
>>>> if you specify USB_ENDPOINT_OUT then you are saying you want the 
>>>> "bytes"
>>>> portion to be sent to the device (HOST TO DEVICE)
>>>>
>>> Good analysis.
>>>
>>> To the OP, if you are new to USB, you may want to go
>>> through the following short introduction to USB.
>>> http://www.usbmadesimple.co.uk/index.html
>>>
>>> In particular, the following section talks about some of
>>> the terminology used in the above.
>>> http://www.usbmadesimple.co.uk/ums_4.htm
>>>
>>> A bit more in detail
>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx 
>>>
>>>
>>> If you want to read more,then the USB 2.0 spec is the best.
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk 
>>
>>
>>
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Travis <lib...@gm...>]

It most likely works in linux because there is little to no validation. 
You are violating USB specifications and Windows is not going to let you 
get away with it. :)

Get your codes working with Windows first then it will probably "just 
work" in linux.

Start with this for PC code:
---
unsigned char myResponseData[64];
int myRequestID = 1;
int myRequestValue = 0;
int myRequestIndex = 0;
usb_control_msg(handle, USB_TYPE_VENDOR | USB_RECIP_DEVICE | 
USB_ENDPOINT_IN, myRequestID, myRequestValue, myRequestIndex, 
myResponseData, sizeof(myResponseData), 1000);
---

The above is valid and correct.  Now fix your firmware so you get the 
response your looking for.

Regards,
Travis

On 2/21/2014 2:22 PM, Rob Willard wrote:
> I would concur, and will speak with my firware guy, however this works
> fine in linux, telling me the firmware is fine.
>
> A further example is the following, which turns on an LED in linux:
>       int t2 = usb_control_msg(handle, USB_RECIP_INTERFACE |
> USB_ENDPOINT_OUT, 10, on   , 0, 0, 0, 10);
>       where on is an int.
>
> receives the following error in Windows:
>       libusb0-dll:err [control_msg] sending control message failed, win
> error: The parameter is incorrect.
>
> I do have a packet sniffer in line with the device, and while I see the
> setup commands fine, there is no packet activity on the requests I have
> been speaking to while under Windows...
>
>
> Here, for reference, is a code snippet that is in the firmware handling
> the requests:
>
> static uint8_t
> 117    USBD_Class_cb_Setup(void *pdev, USB_SETUP_REQ *req) {
> 118            DebugOut(" SU %d %d %d", req->bmRequest, req->bRequest,
> req->wValue);
> 119
> 120            if (req->bRequest == 11) {
> 121                    return RequestSamAD(pdev, req);
> 122            } else if (req->bRequest == 12) {
> 123                    return UsbHandleMic(pdev, req);
> 124            } else if (req->bRequest == 14) {
> 125                    return UsbHandleMult(pdev, req);
> 126            }
> 127
> 128            if (req->bmRequest & 0x80) {
> 129                    // IN (read string from device)
> 130                    switch (req->bRequest) {
> 131                            case 1:
> 132                                    USBD_CtlSendData(pdev, (unsigned
> char *) banner, strlen(banner) + 1);
> 133                                    break;
> 134                            default:
> 135                                    USBD_CtlSendData(pdev, (unsigned
> char *) "what?", 6);
> 136                                    break;
> 137                    }
> 138            } else if (req->wLength > 0) {
> 139                    // OUT (write string to device)
> 140                    USBD_CtlPrepareRx(pdev, ep0recbuff, req->wLength);
> 141            } else {
> 142                    // simple integer command
> 143                    switch (req->bRequest) {
> 144                            case 10:
> 145                                    return RequestLight(pdev, req);
> 146                            default:
> 147                                    return USBD_FAIL;
> 148                    }
> 149            }
> 150            return USBD_OK;
> 151    }
>
>
> Again, very much appreciate the responses I have been getting!
> Rob
>
>
> On 14-02-21 02:04 PM, Travis wrote:
>> You are still sending a "standard" clear feature request:
>>
>> 00000034	8.28595066	libusb0-sys:[clear_feature] recipient: 01 index: 0000 feature: 0000 timeout: 10	
>>
>> I again suggest you use a vendor request type and update your firmware
>> accordingly.  I'd also increase the timeout to 1s for testing.
>>
>> That said, it looks like the request is making it to your device now but
>> it is your device that is not excepting it. Note that you have changed
>> what your device firmware need to look for; did you update your firmware??
>>
>> If I remember correctly, a "A device attached to the system is not
>> functioning." error message after a control request generally means your
>> device did not recognize the request and set a STALL condition.
>>
>> Regards,
>> Travis
>>
>> On 2/21/2014 1:33 PM, Rob Willard wrote:
>>> Thanks for the responses!
>>>
>>> I have read up more, and still have the same type of issues. I have
>>> revisited my request type:
>>>
>>>       usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1,
>>> 0, 0, buff, 64, 10);
>>>
>>> however still recieve errors in Windows (**this works fine under linux
>>> using usb.h). Should return a string, but am getting:
>>>
>>>       libusb0-dll:err [control_msg] sending control message failed, win
>>> error: A device attached to the system is not functioning.
>>>
>>> I did as Xiaofan suggested and loaded the debug version. The output is
>>> attached.
>>>
>>> Any further direction would be most appreciated...
>>>
>>> Rob
>>>
>>>
>>> On 14-02-19 07:52 PM, Xiaofan Chen wrote:
>>>> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>>>>> Greetings,
>>>>>
>>>>> You are trying to use a "standard" usb request for what should be a
>>>>> vendor request type. IE: the 0x01 in the 2nd param.
>>>>>
>>>>> For the 2nd param (request type) you need to use something like the
>>>>> following to perform an action like that:
>>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>>>>> or
>>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>>>>
>>>>> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
>>>>> portion to be returned from the device (DEVICE TO HOST)
>>>>> if you specify USB_ENDPOINT_OUT then you are saying you want the
>>>>> "bytes"
>>>>> portion to be sent to the device (HOST TO DEVICE)
>>>>>
>>>> Good analysis.
>>>>
>>>> To the OP, if you are new to USB, you may want to go
>>>> through the following short introduction to USB.
>>>> http://www.usbmadesimple.co.uk/index.html
>>>>
>>>> In particular, the following section talks about some of
>>>> the terminology used in the above.
>>>> http://www.usbmadesimple.co.uk/ums_4.htm
>>>>
>>>> A bit more in detail
>>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx
>>>>
>>>>
>>>> If you want to read more,then the USB 2.0 spec is the best.
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>>
>>>
>>> _______________________________________________
>>> Libusb-win32-devel mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

Re: [Libusb-win32-devel] usb_control_msg works in linux but not windows

[Rob W. <ro...@sa...>]

Thanks Travis... got this about 2 seconds after sending my last message...

On 14-02-21 02:47 PM, Travis wrote:
> It most likely works in linux because there is little to no validation.
> You are violating USB specifications and Windows is not going to let you
> get away with it. :)
>
> Get your codes working with Windows first then it will probably "just
> work" in linux.
>
> Start with this for PC code:
> ---
> unsigned char myResponseData[64];
> int myRequestID = 1;
> int myRequestValue = 0;
> int myRequestIndex = 0;
> usb_control_msg(handle, USB_TYPE_VENDOR | USB_RECIP_DEVICE |
> USB_ENDPOINT_IN, myRequestID, myRequestValue, myRequestIndex,
> myResponseData, sizeof(myResponseData), 1000);
> ---
>
> The above is valid and correct.  Now fix your firmware so you get the
> response your looking for.
>
> Regards,
> Travis
>
> On 2/21/2014 2:22 PM, Rob Willard wrote:
>> I would concur, and will speak with my firware guy, however this works
>> fine in linux, telling me the firmware is fine.
>>
>> A further example is the following, which turns on an LED in linux:
>>        int t2 = usb_control_msg(handle, USB_RECIP_INTERFACE |
>> USB_ENDPOINT_OUT, 10, on   , 0, 0, 0, 10);
>>        where on is an int.
>>
>> receives the following error in Windows:
>>        libusb0-dll:err [control_msg] sending control message failed, win
>> error: The parameter is incorrect.
>>
>> I do have a packet sniffer in line with the device, and while I see the
>> setup commands fine, there is no packet activity on the requests I have
>> been speaking to while under Windows...
>>
>>
>> Here, for reference, is a code snippet that is in the firmware handling
>> the requests:
>>
>> static uint8_t
>> 117    USBD_Class_cb_Setup(void *pdev, USB_SETUP_REQ *req) {
>> 118            DebugOut(" SU %d %d %d", req->bmRequest, req->bRequest,
>> req->wValue);
>> 119
>> 120            if (req->bRequest == 11) {
>> 121                    return RequestSamAD(pdev, req);
>> 122            } else if (req->bRequest == 12) {
>> 123                    return UsbHandleMic(pdev, req);
>> 124            } else if (req->bRequest == 14) {
>> 125                    return UsbHandleMult(pdev, req);
>> 126            }
>> 127
>> 128            if (req->bmRequest & 0x80) {
>> 129                    // IN (read string from device)
>> 130                    switch (req->bRequest) {
>> 131                            case 1:
>> 132                                    USBD_CtlSendData(pdev, (unsigned
>> char *) banner, strlen(banner) + 1);
>> 133                                    break;
>> 134                            default:
>> 135                                    USBD_CtlSendData(pdev, (unsigned
>> char *) "what?", 6);
>> 136                                    break;
>> 137                    }
>> 138            } else if (req->wLength > 0) {
>> 139                    // OUT (write string to device)
>> 140                    USBD_CtlPrepareRx(pdev, ep0recbuff, req->wLength);
>> 141            } else {
>> 142                    // simple integer command
>> 143                    switch (req->bRequest) {
>> 144                            case 10:
>> 145                                    return RequestLight(pdev, req);
>> 146                            default:
>> 147                                    return USBD_FAIL;
>> 148                    }
>> 149            }
>> 150            return USBD_OK;
>> 151    }
>>
>>
>> Again, very much appreciate the responses I have been getting!
>> Rob
>>
>>
>> On 14-02-21 02:04 PM, Travis wrote:
>>> You are still sending a "standard" clear feature request:
>>>
>>> 00000034	8.28595066	libusb0-sys:[clear_feature] recipient: 01 index: 0000 feature: 0000 timeout: 10	
>>>
>>> I again suggest you use a vendor request type and update your firmware
>>> accordingly.  I'd also increase the timeout to 1s for testing.
>>>
>>> That said, it looks like the request is making it to your device now but
>>> it is your device that is not excepting it. Note that you have changed
>>> what your device firmware need to look for; did you update your firmware??
>>>
>>> If I remember correctly, a "A device attached to the system is not
>>> functioning." error message after a control request generally means your
>>> device did not recognize the request and set a STALL condition.
>>>
>>> Regards,
>>> Travis
>>>
>>> On 2/21/2014 1:33 PM, Rob Willard wrote:
>>>> Thanks for the responses!
>>>>
>>>> I have read up more, and still have the same type of issues. I have
>>>> revisited my request type:
>>>>
>>>>        usb_control_msg(handle, USB_RECIP_INTERFACE | USB_ENDPOINT_IN, 1,
>>>> 0, 0, buff, 64, 10);
>>>>
>>>> however still recieve errors in Windows (**this works fine under linux
>>>> using usb.h). Should return a string, but am getting:
>>>>
>>>>        libusb0-dll:err [control_msg] sending control message failed, win
>>>> error: A device attached to the system is not functioning.
>>>>
>>>> I did as Xiaofan suggested and loaded the debug version. The output is
>>>> attached.
>>>>
>>>> Any further direction would be most appreciated...
>>>>
>>>> Rob
>>>>
>>>>
>>>> On 14-02-19 07:52 PM, Xiaofan Chen wrote:
>>>>> On Thu, Feb 20, 2014 at 9:39 AM, Travis <lib...@gm...> wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> You are trying to use a "standard" usb request for what should be a
>>>>>> vendor request type. IE: the 0x01 in the 2nd param.
>>>>>>
>>>>>> For the 2nd param (request type) you need to use something like the
>>>>>> following to perform an action like that:
>>>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN
>>>>>> or
>>>>>> requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_OUT
>>>>>>
>>>>>> if you specify USB_ENDPOINT_IN then you are saying you want the "bytes"
>>>>>> portion to be returned from the device (DEVICE TO HOST)
>>>>>> if you specify USB_ENDPOINT_OUT then you are saying you want the
>>>>>> "bytes"
>>>>>> portion to be sent to the device (HOST TO DEVICE)
>>>>>>
>>>>> Good analysis.
>>>>>
>>>>> To the OP, if you are new to USB, you may want to go
>>>>> through the following short introduction to USB.
>>>>> http://www.usbmadesimple.co.uk/index.html
>>>>>
>>>>> In particular, the following section talks about some of
>>>>> the terminology used in the above.
>>>>> http://www.usbmadesimple.co.uk/ums_4.htm
>>>>>
>>>>> A bit more in detail
>>>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539261(v=vs.85).aspx
>>>>>
>>>>>
>>>>> If you want to read more,then the USB 2.0 spec is the best.
>>>>>
>>>> ------------------------------------------------------------------------------
>>>> Managing the Performance of Cloud-Based Applications
>>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>>> Read the Whitepaper.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>>>
>>>>
>>>> _______________________________________________
>>>> Libusb-win32-devel mailing list
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Libusb-win32-devel mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel