Prev: IOCTL_USB_GET_NODE_CONNECTION_INFORMATION not working on win2k+OHC
Next: Driver sample with *.asm source
From: Jason Martin <Jason on 19 May 2006 09:34
I have been able to find very little on this error on the net, so I am hoping
the experience of this developer community might be able to help. We
developed and are using a high-speed capable device based on the philips
isp1582 USB device controller/transciever and a DSP. We have been
unsuccessful in getting any success when sending URBs targeted at any
endpoint other than the control endpoint. After exhaustive firmware search,
we have determined that the problem is in fact on the host PC side. All
control transfers work, but I can not make Bulk or interrupt transfers work.
Every attempt results in the same failure:

IoCallDriver fails with error code 0xC0000001 and Urbheader.Status holds
0xC0000011 (USBD_STATUS_XACT_ERROR). I have been unsuccessful in finding ANY
information about the MEANING of this error. What are the possible things
that cause it? I am convinced the problem is not in the firmware of the
device.

Here is some more information (and source):


My pdx->BulkInPipe is a bulk IN pipe with the following attributes:

endpoint address: 129 (0x81)
Interval: right now, it's 0xFF, but I've varied it with no success
MaximumPacketSize: 64 bytes (0x40)



//--------------------------------------------------------------------------------------------
//a bit from DispatchControl (with Debug prints removed) that concerns a
BULK IN IOCTL:

NTSTATUS DispatchControl(PDEVICE_OBJECT fdo, PIRP Irp)
{
PAGED_CODE();
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;

NTSTATUS status = STATUS_SUCCESS;
ULONG info = 0;
UNICODE_STRING sd;
USHORT NewFrequency, AnalogIndex;



status = IoAcquireRemoveLock(&pdx->RemoveLock, Irp);
if (!NT_SUCCESS(status))
return CompleteRequest(Irp, status, 0);

PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
ULONG cbin = stack->Parameters.DeviceIoControl.InputBufferLength;
ULONG cbout = stack->Parameters.DeviceIoControl.OutputBufferLength;
ULONG code = stack->Parameters.DeviceIoControl.IoControlCode;
URB Urb;

switch (code)
{ // process request

case IOCTL_READ_BUFFERED:

UsbBuildInterruptOrBulkTransferRequest(&Urb,
sizeof(_URB_BULK_OR_INTERRUPT_TRANSFER),
pdx->BulkInPipe,
Irp->AssociatedIrp.SystemBuffer, NULL, cbout,
USBD_TRANSFER_DIRECTION_IN | USBD_SHORT_TRANSFER_OK, NULL);


status = SendAwaitUrb(fdo, &Urb);

break;

}
}


//--------------------------------------------------------------------------------------------
//Modified version of Walter Oney's SendAwaitUrb routine (again, shortened
to show only relevant parts):


NTSTATUS SendAwaitUrb(PDEVICE_OBJECT fdo, PURB urb)
{ // SendAwaitUrb
PAGED_CODE();
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;

KEVENT event;
KeInitializeEvent(&event, NotificationEvent, FALSE);

IO_STATUS_BLOCK iostatus;
PIRP Irp = IoBuildDeviceIoControlRequest(IOCTL_INTERNAL_USB_SUBMIT_URB,
pdx->LowerDeviceObject, NULL, 0, NULL, 0, TRUE, &event, &iostatus);

if (!Irp)
{
return STATUS_INSUFFICIENT_RESOURCES;
}

PIO_STACK_LOCATION stack = IoGetNextIrpStackLocation(Irp);
stack->Parameters.Others.Argument1 = (PVOID) urb;
NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);


if (status == STATUS_PENDING)
{
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);

status = iostatus.Status;
}
return status;
} // SendAwaitUrb


//--------------------------------------------------------------------------------------------


Irp->AssociatedIrp.SystemBuffer contains 64 bytes at the call to
UsbBuildInterruptOrBulkTransferRequest. The call to IoCallDriver returns
iostatus.status = 0xC0000001

(STATUS_UNSUCCESSFUL - wonderfully descriptive) and the Urb.Urbheader.Status
yeilds 0xC0000011 (USBD_STATUS_XACT_ERROR). Neither of these tell me anything
that can help me

trace this error down. Any help would be appreciated! Thanks in advance,


Jason Martin
From: Jason Martin on 19 May 2006 11:41
This problem has been resolved. Amazingly, we've had this problem for weeks
and it wasn't until I posted that we found the solution ourselves. For any
others who run into this problem, here is what it was:

Firmware. We were certain the firmware was working, but it was not. The
device was not properly configured to respond to the IN token and therefore
did nothing - hence the "transaction error." Fixing this error, the driver
code worked perfectly fine. If anyone knows how to obtain more specific
information on this error message, I'd still like to hear it
(USBD_STATUS_XACT_ERROR) - but it seems that it was just a failure of the
device to behave as expected. Thanks,


Jason Martin

From: slsnios on 10 Jun 2006 03:27

Hi Jason Martin ,
I am working on USB2.0 high speed device and i am getting the error
like u got in ur development.Actuallly my usb2.0 device working fine on
my PC but i is not working on another PC.I develop driver for usb
communication and its working fine.I test it on many number of and its
working fine. But why i m getting this type of error in another machine
thts my main problem?
Hope u can focus me on firmware.I think there will b some problem on
tht but wht is it??Can u help me for this??
Best Regards,
Tejas



--
slsnios
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------

From: Tim Roberts on 17 Jun 2006 20:27
slsnios <slsnios.29jrpc(a)mail.codecomments.com> wrote:
>
>Hi Jason Martin ,
>I am working on USB2.0 high speed device and i am getting the error
>like u got in ur development.Actuallly my usb2.0 device working fine on
>my PC but i is not working on another PC.I develop driver for usb
>communication and its working fine.I test it on many number of and its
>working fine. But why i m getting this type of error in another machine
>thts my main problem?
>Hope u can focus me on firmware.I think there will b some problem on
>tht but wht is it??Can u help me for this??

Do you have a USB analyzer, so you can watch the packets? Jason's problem
was that his firmware occasionally did not respond to an IN token.
--
- Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
 | 
Pages: 1
Prev: IOCTL_USB_GET_NODE_CONNECTION_INFORMATION not working on win2k+OHC
Next: Driver sample with *.asm source