I have a thread in my driver that will sit and listen for USB data from our
device. The device should send a total of 128 bytes of data back in 8 byte
(max packet length) segments. I create an URB using
“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I submit
the IRP, and if the status is pending I wait on the event passed to
IoBuildDeviceIoControlRequest.
The first time data is available, the wait completes, and my transfer buffer
has data in it. I then create a new IRP and re submit it down to the USB
bus driver… at this point it will wait until the next time data is ready
(instead of getting the rest of the 128 bytes that it should be reading).
Is my approach of re-creating and submitting the IRP incorrect? why
wouldn’t I be getting all the data from the bus driver in one read if I pass
it a large buffer?
Thanks in advance.
-Jeff
Jeff Lange wrote:
I have a thread in my driver that will sit and listen for USB data from our
device. The device should send a total of 128 bytes of data back in 8 byte
(max packet length) segments. I create an URB using
“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I submit
the IRP, and if the status is pending I wait on the event passed to
IoBuildDeviceIoControlRequest.
How large is the buffer in your URB? How many bytes are you getting
back in that first completion? Generally, a bulk URB will not complete
until it is full or cancelled.
The first time data is available, the wait completes, and my transfer buffer
has data in it. I then create a new IRP and re submit it down to the USB
bus driver… at this point it will wait until the next time data is ready
(instead of getting the rest of the 128 bytes that it should be reading).
Does your device hold the data until more requests come in? Remember
that, if there is no URB queued up at the beginning of a frame, the host
interface driver will not issue an IN token for your endpoint, so there
will be no opportunity for the device to send data. If you need
continuous transfers, you should queue up 3 (or more) URBs at a time, so
there’s always one ready while you are processing the last one.
–
You should read from your device in terms of device protocol, not bus
protocol. Let’s say your message size is 128 bytes. Just send a read
of 128 bytes down to the device.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, March 29, 2005 2:08 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bulk usb read question
Jeff Lange wrote:
I have a thread in my driver that will sit and listen for USB data from
our
device. The device should send a total of 128 bytes of data back in 8
byte
(max packet length) segments. I create an URB using
“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I
submit
the IRP, and if the status is pending I wait on the event passed to
IoBuildDeviceIoControlRequest.
How large is the buffer in your URB? How many bytes are you getting
back in that first completion? Generally, a bulk URB will not complete
until it is full or cancelled.
The first time data is available, the wait completes, and my transfer
buffer
has data in it. I then create a new IRP and re submit it down to the
USB
bus driver… at this point it will wait until the next time data is
ready
(instead of getting the rest of the 128 bytes that it should be
reading).
Does your device hold the data until more requests come in? Remember
that, if there is no URB queued up at the beginning of a frame, the host
interface driver will not issue an IN token for your endpoint, so there
will be no opportunity for the device to send data. If you need
continuous transfers, you should queue up 3 (or more) URBs at a time, so
there’s always one ready while you are processing the last one.
–
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Is my approach of re-creating and submitting the IRP incorrect? why
wouldn’t I be getting all the data from the bus driver in one read if I pass
it a large buffer?
What kind of USB pipe are you using?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>How large is the buffer in your URB? How many bytes are you getting back
in that first completion? Generally, a bulk URB will not complete until it
is full or cancelled.
I’m passing it a buffer of 128 bytes. on the first read it will return 9
bytes.
The device is a generic HID device, so without my driver installed I hooked
up a usb sniffer (snoopy) and listened to the data going back and forth
between the device and the generic windows HID driver… the read went like
this…
read 9 bytes,
read 13 bytes,
read 1 byte,
read 65 bytes,
read 9 bytes,
read 31 bytes.
all of these reads happen in succession as soon as I make data available on
the device.
the strangest part is that when using my driver, the read of the first 9
bytes is correct, the second time I make data available, it says it returns
17 bytes… looking at the buffer, the first 8 bytes are what would be the
first 8 bytes of the second data read, and the last 9 is the data from the
first read ( 22222222111111111) (I’m using 1 and 2 to show which read the
data should have come from)
Thanks.
-Jeff
“Jeff Lange” wrote in message
news:xxxxx@ntdev…
>I have a thread in my driver that will sit and listen for USB data from our
>device. The device should send a total of 128 bytes of data back in 8 byte
>(max packet length) segments. I create an URB using
>“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
>IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I submit
>the IRP, and if the status is pending I wait on the event passed to
>IoBuildDeviceIoControlRequest.
>
> The first time data is available, the wait completes, and my transfer
> buffer has data in it. I then create a new IRP and re submit it down to
> the USB bus driver… at this point it will wait until the next time data
> is ready (instead of getting the rest of the 128 bytes that it should be
> reading).
>
> Is my approach of re-creating and submitting the IRP incorrect? why
> wouldn’t I be getting all the data from the bus driver in one read if I
> pass it a large buffer?
>
> Thanks in advance.
>
> -Jeff
>
>
>
I was just informed by the hardware engineer that the device is actually
operating at USB 1.1 low-speed, so it’s not a bulk transfer, it’s interrupt.
I’m not sure how much of a difference that makes, but that might explain why
it takes a bunch of reads to get all the data.
-Jeff
“Jeff Lange” wrote in message
news:xxxxx@ntdev…
>I have a thread in my driver that will sit and listen for USB data from our
>device. The device should send a total of 128 bytes of data back in 8 byte
>(max packet length) segments. I create an URB using
>“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
>IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I submit
>the IRP, and if the status is pending I wait on the event passed to
>IoBuildDeviceIoControlRequest.
>
> The first time data is available, the wait completes, and my transfer
> buffer has data in it. I then create a new IRP and re submit it down to
> the USB bus driver… at this point it will wait until the next time data
> is ready (instead of getting the rest of the 128 bytes that it should be
> reading).
>
> Is my approach of re-creating and submitting the IRP incorrect? why
> wouldn’t I be getting all the data from the bus driver in one read if I
> pass it a large buffer?
>
> Thanks in advance.
>
> -Jeff
>
>
>
if this is a duplicate please forgive me, I wrote this message once and sent
it but it never showed up on the list…
How large is the buffer in your URB? How many bytes are you getting back
in that first completion? Generally, a bulk URB will not complete until it
is full or cancelled.
I’m passing it a buffer of 128 bytes. on the first read it will return 9
bytes.
The device is a generic HID device, so without my driver installed I hooked
up a usb sniffer (snoopy) and listened to the data going back and forth
between the device and the generic windows HID driver… the read went like
this…
read 9 bytes,
read 13 bytes,
read 1 byte,
read 65 bytes,
read 9 bytes,
read 31 bytes.
all of these reads happen in succession as soon as I make data available on
the device.
the strangest part is that when using my driver, the read of the first 9
bytes is correct, the second time I make data available, it says it returns
17 bytes… looking at the buffer, the first 8 bytes are what would be the
first 8 bytes of the second data read, and the last 9 is the data from the
first read ( 22222222111111111) (I’m using 1 and 2 to show which read the
data should have come from)
Thanks.
-Jeff
“Jeff Lange” wrote in message
news:xxxxx@ntdev…
>I have a thread in my driver that will sit and listen for USB data from our
>device. The device should send a total of 128 bytes of data back in 8 byte
>(max packet length) segments. I create an URB using
>“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
>IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I submit
>the IRP, and if the status is pending I wait on the event passed to
>IoBuildDeviceIoControlRequest.
>
> The first time data is available, the wait completes, and my transfer
> buffer has data in it. I then create a new IRP and re submit it down to
> the USB bus driver… at this point it will wait until the next time data
> is ready (instead of getting the rest of the 128 bytes that it should be
> reading).
>
> Is my approach of re-creating and submitting the IRP incorrect? why
> wouldn’t I be getting all the data from the bus driver in one read if I
> pass it a large buffer?
>
> Thanks in advance.
>
> -Jeff
>
>
>
We have resolved the problem.
It turns out that the device was sending short packets in the middle of the
data stream rather then always sending 8 byte packets except for the last
one. This meant that the bus driver thought the transfer was finished and
it completed my IRP. we changed the firmware in the device to always sent 8
byte packets and everything is much better now.
This still doesn’t explain why I couldn’t get the remainder of the data when
I submitted the next IRP though. As that is what the windows HID driver
did… oh well.
Thanks!
-Jeff
“Jeff Lange” wrote in message
news:xxxxx@ntdev…
>I have a thread in my driver that will sit and listen for USB data from our
>device. The device should send a total of 128 bytes of data back in 8 byte
>(max packet length) segments. I create an URB using
>“UsbBuildInterruptOrBulkTransferRequest()” and I create an IRP using
>IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB…) I submit
>the IRP, and if the status is pending I wait on the event passed to
>IoBuildDeviceIoControlRequest.
>
> The first time data is available, the wait completes, and my transfer
> buffer has data in it. I then create a new IRP and re submit it down to
> the USB bus driver… at this point it will wait until the next time data
> is ready (instead of getting the rest of the 128 bytes that it should be
> reading).
>
> Is my approach of re-creating and submitting the IRP incorrect? why
> wouldn’t I be getting all the data from the bus driver in one read if I
> pass it a large buffer?
>
> Thanks in advance.
>
> -Jeff
>
>
>