Unexpected get status request

QNX Newsgroups (Archives) qdn.public.ddk.usb
1

I am developing a driver application and monitoring bus activity using a
Hitex USB Agent.

I need to send the USB device some set-up info shortly after enumeration and
prior to the commencement of polling. The crucial bit of the device
insertion callback goes as follows :

{

//---- Carry out enumeration and connect pipes

sleep(1);
if( pod->ep_cntl_buff ) {

pod->ep_cntl_buf[0] = 21;
turb = usbd_alloc_urb( NULL );

usbd_setup_bulk( turb, URB_DIR_OUT, pod->ep_cntl_buf, 6 );
usbd_io( turb, pod->ep_cntl, NULL, pod, USBD_TIME_INFINITY );
}

//---- Start polling
}

The result on the bus is…

__
1230____: Idle(14) EOP(0x2)

__
1231____: Idle(5) SYNC(00000001) SETUP(0x2d) ADDR(0x1) EP(0x0) CRC5(0x17)

__
1232____: Idle(5) SYNC(00000001) DATA0(0xc3) DATA(0 00 00 00 00 00 06 00)
CRC16(0x3d2a)

__
1233____: Idle(6) SYNC(00000001) ACK(0xd2)

__
1234____: Idle(16) EOP(0x2)

__
1235____: Idle(14) EOP(0x2)

__
1236____: Idle(4) SYNC(00000001) OUT(0xe1) ADDR(0x1) EP(0x0) CRC5(0x17)

__
1237____: Idle(5) SYNC(00000001) DATA1(0x4b) DATA(15 00 00 00 00 00)
CRC16(0xbf84)

__
1238____: Idle(6) SYNC(00000001) STALL(0x1e)

__
1239____: Idle(16) EOP(0x2)


The SETUP message (frames 1231 + 1232) is a GET_STATUS, and the bulk
transfer is 1236 + 1237.

The fact that the USB device does not respond to the GET_STATUS and the
subsequent STALL is my problem.

My question is, does the USB stack always send out a request for status
prior to performing an OUT data transfer to a device?

TIA
Jim Douglas

2

Jim Douglas <jim@dramatec.co.uk> wrote:

I am developing a driver application and monitoring bus activity using a
Hitex USB Agent.

I need to send the USB device some set-up info shortly after enumeration and
prior to the commencement of polling. The crucial bit of the device
insertion callback goes as follows :

{

//---- Carry out enumeration and connect pipes

sleep(1);
if( pod->ep_cntl_buff ) {

pod->ep_cntl_buf[0] = 21;
turb = usbd_alloc_urb( NULL );

usbd_setup_bulk( turb, URB_DIR_OUT, pod->ep_cntl_buf, 6 );
usbd_io( turb, pod->ep_cntl, NULL, pod, USBD_TIME_INFINITY );
}

//---- Start polling
}

The result on the bus is…

[snip]

I didn’t think your device had a bulk endpoint? If it does, then you
are calling usbd_io on the wrong endpoint. If you are trying to send
data over the control endpoint, you should be using the usbd_setup_vendor
function. The printer driver source included in the ddk shows how to
use the function.

3

“Kevin Chiles” <kchiles@qnx.com> wrote in message
news:97188u$6sb$1@nntp.qnx.com…

[snip]

I didn’t think your device had a bulk endpoint? If it does, then you
are calling usbd_io on the wrong endpoint. If you are trying to send
data over the control endpoint, you should be using the usbd_setup_vendor
function. The printer driver source included in the ddk shows how to
use the function.

OK. To put a little flesh on the bare bones of the documentation, would I be
correct as follows -

  1. The name ‘usbd_setup_vendor’ is bit misleading. It is really a
    convenience function that prepares a general purpose SETUP message?
  2. The only time it is a proper vendor command is when the USB_TYPE_VENDOR
    flag is used?
  3. The reason it’s like this is ‘usbd_setup_control’ is missing/not
    finished?

Jim Douglas

4

Jim Douglas <jim@dramatec.co.uk> wrote:

“Kevin Chiles” <> kchiles@qnx.com> > wrote in message
news:97188u$6sb$> 1@nntp.qnx.com> …

[snip]

I didn’t think your device had a bulk endpoint? If it does, then you
are calling usbd_io on the wrong endpoint. If you are trying to send
data over the control endpoint, you should be using the usbd_setup_vendor
function. The printer driver source included in the ddk shows how to
use the function.

OK. To put a little flesh on the bare bones of the documentation, would I be
correct as follows -

  1. The name ‘usbd_setup_vendor’ is bit misleading. It is really a
    convenience function that prepares a general purpose SETUP message?

Yes.

  1. The only time it is a proper vendor command is when the USB_TYPE_VENDOR
    flag is used?

Yes. You can use any of the USB_TYPE_XXXX / USB_RECIPIENT_XXXX flags.

  1. The reason it’s like this is ‘usbd_setup_control’ is missing/not
    finished?

No. The original thought behind the usbd_setup_control function
was to allow a driver to build its own setup packet, but since
usbd_setup_vendor allows for any type of transfer on the control
endpoint it was not implemented.