Re: Is there a way to request the current status of a usb pipe/endpoint?
- From: "Linda" <linda.marcellus@xxxxxxxxxx>
- Date: 19 Feb 2007 20:00:58 -0800
On Feb 18, 11:35 pm, "Subodh Radheshyam Gupta"
<Subodh.Radheshyam.Gu...@xxxxxxxxx> wrote:
On Feb 17, 3:44 am, "Linda" <linda.marcel...@xxxxxxxxxx> wrote:
My driver continuously polls the device's bulk in endpoint for data by
creating a IRP_MJ_INTERNAL_DEVICE_CONTROL Irp with a URB built using
UsbBuildInterruptOrBulkTransferRequest() with the flags set to
(USBD_SHORT_TRANSFER_OK | USBD_TRANSFER_DIRECTION_IN). If the Irp
completes successfully, the completion routine reuses it to request
more data.
When the device boots up, it sends 1536 bytes in 64-byte packets
except for the last 2 which are 63 bytes and 1 byte. (This was
because of problems with DMA if the block of data to be transmitted is
a multiple of 64). After that, in response to commands, the device
sends 24 byte responses.
For some reason, my driver sees the 1536 bytes, but not the next 24
byte response, but it does see all subsequent 24 byte responses.
Using a protocol analyzer, I know the device is sending all the 24
byte responses.
I've also monitored the transactions with two different software usb
monitors, neither of which see the missing data.
Through trial and error, I've found that the first 24 byte response
will be seen if I reset the pipe using URB_FUNCTION_RESET_PIPE.
However, my Irp is always completing with both the IoStatus.Status and
URB status showing success, even when I haven't reset the pipe. It's
just that if I don't reset the pipe, I miss the first 24-byte
response. So how can I know when I need to reset the pipe?
I've also observed that if the device firmware is modified so the last
two packets are sent as 60 bytes and 4 bytes instead of 63 and 1, the
problem does not occur.
Here's the relevant code from my completion routine (with error
checking and debugging removed):
NTSTATUS OnCompleteUsbReaderIrp (PDEVICE_OBJECT pFdo_, PIRP pIrp_,
PURB pUrb_)
{ // OnCompleteUsbReaderIrp
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) pFdo_->DeviceExtension;
PUSB_READER pUsbRdr = &pdx->UsbReader;
ULONG seglen = 0; // length of next read request
BOOLEAN bReuseIrp = true;
USBD_STATUS urbstatus = URB_STATUS(pUrb_);
if (!USBD_SUCCESS(urbstatus) || !NT_SUCCESS ( pIrp_->IoStatus.Status ))
bReuseIrp = false;
// If Irp completed without error, update our buffer and calculate
length of next read
.... code ommitted for simplification ....
if ( bReuseIrp )
{
// Reinitialize the URB so we can request more data
RtlZeroMemory ( pUrb_, sizeof(URB) );
UsbBuildInterruptOrBulkTransferRequest (
pUrb_,
sizeof(_URB_BULK_OR_INTERRUPT_TRANSFER),
pdx->hInPipe,
pUsbRdr->pucBuffer,
NULL,
seglen,
USBD_SHORT_TRANSFER_OK | USBD_TRANSFER_DIRECTION_IN,
NULL );
// Reuse the irp
UCHAR flags = pIrp_->AllocationFlags;
CCHAR nstack = pIrp_->StackCount;
IoInitializeIrp (pIrp_,IoSizeOfIrp(nstack),nstack);
pIrp_->AllocationFlags = flags;
pIrp_->IoStatus.Status = STATUS_SUCCESS;
// Set up the first (our) stack location in the Irp
PIO_STACK_LOCATION stack = IoGetNextIrpStackLocation ( pIrp_ );
stack->DeviceObject = pFdo_;
// Set up next stack location
IoSetNextIrpStackLocation( pIrp_ );
stack = IoGetNextIrpStackLocation ( pIrp_ );
stack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
stack->Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB;
stack->Parameters.Others.Argument1 = (PVOID) pUrb_;
IoSetCompletionRoutine ( pIrp_, (PIO_COMPLETION_ROUTINE)
OnCompleteUsbReaderIrp,
(PVOID) pUrb_, TRUE, TRUE, TRUE );
// Pass the recycled IRP down and ignore the return code from
IoCallDriver. If
// this stage gets completed synchronously, this very completion
routine will
// already have been called recursively to deal with it. If not,
the IRP is
// now active again. In either case, we want the current
invocation IoCompleteRequest
// to stop working on this IRP.
IoCallDriver ( pdx->LowerDeviceObject, pIrp_ );
}
// We created this IRP, so we always halt completion processing by
returning
// STATUS_MORE_PROCESSING_REQUIRED
return STATUS_MORE_PROCESSING_REQUIRED;
} // OnCompleteUsbReaderIrp
Any insights would be appreciated as I've been banging my head against
the wall for a couple of weeks now!
Try removing USBD_SHORT_TRANSFER_OK for the first transfer.
-Subodh- Hide quoted text -
- Show quoted text -
Thanks for the suggestion but that won't work. I can't always
guarantee how much data the device will send. This is just one case.
So short transfers are always acceptable.
.
- Follow-Ups:
- References:
- Is there a way to request the current status of a usb pipe/endpoint?
- From: Linda
- Re: Is there a way to request the current status of a usb pipe/endpoint?
- From: Subodh Radheshyam Gupta
- Is there a way to request the current status of a usb pipe/endpoint?
- Prev by Date: Re: Can a pipe be bigger than 64 byte?
- Next by Date: Re: CreateFile and GetVolumeInformation fail
- Previous by thread: Re: Is there a way to request the current status of a usb pipe/endpoint?
- Next by thread: Re: Is there a way to request the current status of a usb pipe/endpoint?
- Index(es):
Relevant Pages
|
