libusb-devel

[Libusb-devel] what does a LIBUSB_TRANSFER_STALL on control transfer mean?

[bob 2. <ica...@29...>]

I'm still very much a USB/libusb-1.0 newbie.

I've been trying to teach myself the libusb-1.0 library against a Phidgets SBC 
board.    This board comes with libusb-0.1 source code,  albeit a tad 
difficult to follow.   The relevant libusb-0.1 call I'm trying to emulate in 
async libusb-1.0 is:

=========  begin Phidget lib snip =============
 BytesWritten = usb_control_msg((usb_dev_handle *)phid->deviceHandle,
                                        USB_ENDPOINT_OUT | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
                                        USB_REQ_SET_CONFIGURATION,
                                        0x0200, /* value */
                                        phid->deviceDef->pdd_iid, /* index*/
                                        (char *)buffer,
                                        phid->outputReportByteLength, /* size 
*/
                                        500); /* FIXME? timeout */
=========== end Phidget lib snip ===========



Recently I tried programming an async control transfer message by adding some 
modifications to the dpfp.c example (documented at 
http://www.icanprogram.com/opndrs/phidgets/2012Apr13.html).    The relevant 
code is:

========== begin my dpfp.c snip =============

libusb_fill_control_setup(ctrlbuf, 
		LIBUSB_ENDPOINT_OUT | LIBUSB_REQUEST_TYPE_CLASS |
		LIBUSB_RECIPIENT_INTERFACE,
		0x09,
		0x0200,
		0,
		6);

	ctrlbuf[8]=0x1;

printf("go2: ctrlbuf0-7]=0x%X-%X-%X-%X-%X-%X-%X-%X\n",
		ctrlbuf[0],
		ctrlbuf[1],
		ctrlbuf[2],
		ctrlbuf[3],
		ctrlbuf[4],
		ctrlbuf[5],
		ctrlbuf[6],
		ctrlbuf[7]);

printf("go3: ctrlbuf[8-15]=0x%X-%X-%X-%X-%X-%X-%X-%X\n",
		ctrlbuf[8],
		ctrlbuf[9],
		ctrlbuf[10],
		ctrlbuf[11],
		ctrlbuf[12],
		ctrlbuf[13],
		ctrlbuf[14],
		ctrlbuf[15]);


	libusb_fill_control_transfer(ctrl_transfer, devh, ctrlbuf,
		cb_ctrl, NULL, 0);


========== end my dpfp.c snip ==============

    

What does it mean when the control transfer returns a LIBUSB_TRANSFER_STALL?

Thanks in advance for your help.

bob

Re: [Libusb-devel] what does a LIBUSB_TRANSFER_STALL on control transfer mean?

[Tim R. <ti...@pr...>]

bob 295 wrote:
> I'm still very much a USB/libusb-1.0 newbie.
>
> I've been trying to teach myself the libusb-1.0 library against a Phidgets SBC 
> board.

OK, that tells us the computer you're running this on, but not the
device you are trying to communicate with.  What kind of device are you
trying to contact?

> This board comes with libusb-0.1 source code,  albeit a tad 
> difficult to follow.   The relevant libusb-0.1 call I'm trying to emulate in 
> async libusb-1.0 is:
>
> =========  begin Phidget lib snip =============
>  BytesWritten = usb_control_msg((usb_dev_handle *)phid->deviceHandle,
>                                         USB_ENDPOINT_OUT | USB_TYPE_CLASS |
> USB_RECIP_INTERFACE,
>                                         USB_REQ_SET_CONFIGURATION,
>                                         0x0200, /* value */
>                                         phid->deviceDef->pdd_iid, /* index*/
>                                         (char *)buffer,
>                                         phid->outputReportByteLength, /* size 
> */
>                                         500); /* FIXME? timeout */
> =========== end Phidget lib snip ===========
>
> Recently I tried programming an async control transfer message by adding some 
> modifications to the dpfp.c example (documented at 
> http://www.icanprogram.com/opndrs/phidgets/2012Apr13.html).

That sample is for a U.are.U 4000B fingerprint scanner.  Do you actually
have a U.are.U 4000B fingerprint scanner?  If not, then the sample code
is not going to be terribly helpful.


> The relevant code is:
>
> ========== begin my dpfp.c snip =============
>
> libusb_fill_control_setup(ctrlbuf, 
> 		LIBUSB_ENDPOINT_OUT | LIBUSB_REQUEST_TYPE_CLASS |
> 		LIBUSB_RECIPIENT_INTERFACE,
> 		0x09,
> 		0x0200,
> 		0,
> 		6);
>
> 	ctrlbuf[8]=0x1;

That sets up a control transfer, but it does not actually SEND the
command.  You need libusb_submit_transfer to send this command to the
device.

 
> What does it mean when the control transfer returns a LIBUSB_TRANSFER_STALL?

A stall means the device did not recognize your command.  Do you
actually have this device?

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Re: [Libusb-devel] what does a LIBUSB_TRANSFER_STALL on control transfer mean?

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

On Fri, Apr 13, 2012 at 11:03 PM, bob 295 <ica...@29...> wrote:
> I'm still very much a USB/libusb-1.0 newbie.
>
> I've been trying to teach myself the libusb-1.0 library against a Phidgets SBC
> board.    This board comes with libusb-0.1 source code,  albeit a tad
> difficult to follow.   The relevant libusb-0.1 call I'm trying to emulate in
> async libusb-1.0 is:
>
> =========  begin Phidget lib snip =============
>  BytesWritten = usb_control_msg((usb_dev_handle *)phid->deviceHandle,
>                                        USB_ENDPOINT_OUT | USB_TYPE_CLASS |
> USB_RECIP_INTERFACE,
>                                        USB_REQ_SET_CONFIGURATION,
>                                        0x0200, /* value */
>                                        phid->deviceDef->pdd_iid, /* index*/
>                                        (char *)buffer,
>                                        phid->outputReportByteLength, /* size
> */
>                                        500); /* FIXME? timeout */
> =========== end Phidget lib snip ===========

In this case, I will suggest you not to jump from synchronous
transfer to async transfer in your first trying of libusb-1.0.

Try to translate the above sync control transfer to the
sync control transfer libusb-1.0 API first. Once that is
working, then you can try async API.


-- 
Xiaofan

Re: [Libusb-devel] what does a LIBUSB_TRANSFER_STALL on control transfer mean?

[Peter S. <pe...@st...>]

bob 295 wrote:
> The relevant libusb-0.1 call I'm trying to emulate in async

First do it with sync.


> libusb-1.0 is:
> 
> =========  begin Phidget lib snip =============
>  BytesWritten = usb_control_msg((usb_dev_handle *)phid->deviceHandle,
>                                         USB_ENDPOINT_OUT | USB_TYPE_CLASS |
> USB_RECIP_INTERFACE,
>                                         USB_REQ_SET_CONFIGURATION,
>                                         0x0200, /* value */
>                                         phid->deviceDef->pdd_iid, /* index*/
>                                         (char *)buffer,
>                                         phid->outputReportByteLength, /* size 
> */
>                                         500); /* FIXME? timeout */
> =========== end Phidget lib snip ===========

BytesWritten = libusb_control_transfer(phid->deviceHandle,
  LIBUSB_REQUEST_TYPE_CLASS | LIBUSB_RECIPIENT_INTERFACE,
  0x09, 0x200, phid->deviceDef->pdd_idd,
  buffer, phid->outputReportByteLength, 500);

As you see the conversion is quite straightforward.

But since the Phidgets devices all abuse the HID class you should
really be using HIDAPI instead of libusb. For some discussion, see:

http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass


> What does it mean when the control transfer returns a
> LIBUSB_TRANSFER_STALL?

That the device does not support your request. See
8.5.3.1 Reporting Status Results page 227 of USB 2.0 spec.


//Peter