Re: usb_control_msg works in linux but not windows

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 <[email protected]> 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
> [email protected]
> 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