Hi guys,
I’m having a device generating at every 250 ms a 64 byte interupt message
towards the host. Thus my descriptor is a INT-IN descriptor.
I’ve installed in the corresponding Windows driver a continous reader to
poll on that.
I see the interrupts leaving the device (as the end of transfer interrupts
arrive to the device) but from the PC side I can only see ClearHalts being
sent to the device and the corresponding message in TraceView.
00000196 kmdf 4 60 0 201 11\13\2009-19:48:08:281 JTBoxEvtUsbTargetPipeReadersFailed Pipe 0x7C11A358, NTSTATUS 0xc0000001, UsbdStatus 0x0
Can anybody tell me what are the situations when the XP USB stack doesn’t
“accept” my transfers?
Or what can be the problem?
Thanks
xxxxx@chello.hu wrote:
I’m having a device generating at every 250 ms a 64 byte interupt message
towards the host. Thus my descriptor is a INT-IN descriptor.
What does the descriptor look like, exactly? Full-speed or high-speed
device? The Windows USB stack does not support intervals longer than 32
frames. Your device doesn’t have to SEND data that often, but the
descriptor interval needs to be shorter.
I’ve installed in the corresponding Windows driver a continous reader to
poll on that.
I see the interrupts leaving the device (as the end of transfer interrupts
arrive to the device) but from the PC side I can only see ClearHalts being
sent to the device and the corresponding message in TraceView.
00000196 kmdf 4 60 0 201 11\13\2009-19:48:08:281 JTBoxEvtUsbTargetPipeReadersFailed Pipe 0x7C11A358, NTSTATUS 0xc0000001, UsbdStatus 0x0
Odd. Does this return immediately (indicating parameter problem), or
does the timing match the data packets coming back?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
it is a full speed device, and the the message comes after the packet has arrived, not right
after running the reader. Also have to mention that the driver works flawlessly for another
USB2.0 (although high-speed) device.
And finally I also have to mention that sending 32 bytes works just fine (I figured it out
in the meantime by simple tests).
Is there a way to make it work larger than 32 bytes? I mean isn’t that possible for me to send
data from the device in larger snippets? (I’m not sticking for my endpoint to be an
INT ep it can be bulk-in as well (for my other HS device the reader just works fine on bulk-in
as well and can read 512 bytes at once painlessly, but if I try this with 256 bytes on my
FS device it doesn’t work at all).
Thanks,
xxxxx@chello.hu wrote:
it is a full speed device, and the the message comes after the packet has arrived, not right
after running the reader. Also have to mention that the driver works flawlessly for another
USB2.0 (although high-speed) device.
And finally I also have to mention that sending 32 bytes works just fine (I figured it out
in the meantime by simple tests).
By that, do you mean you changed the packet size in the descriptor to 32
bytes, or you changed the TransferLength in the continuous reader
request to 32 bytes, or both? Can you show us the continuous reader
configuration code for the 64-byte case that failed, and the descriptors?
Is there a way to make it work larger than 32 bytes? I mean isn’t that possible for me to send
data from the device in larger snippets?
Yes, it should work just fine with 64-byte packets.
(I’m not sticking for my endpoint to be an
INT ep it can be bulk-in as well (for my other HS device the reader just works fine on bulk-in
as well and can read 512 bytes at once painlessly, but if I try this with 256 bytes on my
FS device it doesn’t work at all).
No, that’s not legal for a full-speed device. Full-speed interrupt and
bulk endpoints are limited to 64-byte packets.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi guys,
I am lame as hell 
I forgot to change the transfer buffer size in my WDF driver code
Thanks Tim for pointing that out!!
Cheers,
t.