KMDF & USB isochronous
in [Device Drivers]
|
From: Gopalakrishnan on 21 Sep 2006 08:41 Hi Eliyas, I used the sample code in src\kmdf\USBSAMP in the Vista RC1 WDK to read from isochronous pipe instead of my code. Following is the output from the driver as soon as the read request is sent, UsbSamp: SubRequestCompletionRoutine - begins UsbSamp: read-write irp failed with status C0000001 UsbSamp: urb header status C0000B00 UsbSamp: IsoPacket[0].Length = 0 IsoPacket[0].Status = C0000005 UsbSamp: IsoPacket[1].Length = 0 IsoPacket[1].Status = C0000005 UsbSamp: no more pending sub requests UsbSamp: Total data transferred = 0 UsbSamp: SubRequestCompletionRoutine Read completed UsbSamp: SubRequestCompletionRoutine - ends My device supports upto Fullspeed only. Can you please infer what could be the possible reason for the failure. Thanks, Gopalakrishnan. "Eliyas Yakub [MSFT]" wrote: > Can you dump the IFR log of your driver to see whether the request was > failed by framework or by the underlying USB stack? > > http://www.microsoft.com/whdc/driver/wdf/KMDF-build.mspx > -- > -Eliyas > This posting is provided "AS IS" with no warranties, and confers no rights. > http://www.microsoft.com/whdc/driver/tips/default.mspx > >
From: Gopalakrishnan on 21 Sep 2006 09:35 Hi Eliyas, In continuation with my last post, the following is the trace message that I got when I tried to transfer 80 bytes of data from the device to host using isochronous pipe. UsbSamp: PerformFullSpeedIsochTransfer Read - begins UsbSamp: totalLength = 80 UsbSamp: packetSize = 64 UsbSamp: PerformFullSpeedIsochTransfer::stageSize = 80 UsbSamp: PerformFullSpeedIsochTransfer::numSubRequests = 1 UsbSamp: nPackets = 2 for Irp/URB pair 0 Sending subRequest 0x7DECEBA8 UsbSamp: SubRequestCompletionRoutine - begins UsbSamp: rwContext->Numxfer = 80 UsbSamp: IsoPacket[0].Length = 40 IsoPacket[0].Status = 0 UsbSamp: IsoPacket[1].Length = 10 IsoPacket[1].Status = C000000C UsbSamp: no more pending sub requests UsbSamp: urb start frame F22B UsbSamp: Total data transferred = 50 UsbSamp: SubRequestCompletionRoutine Read completed UsbSamp: SubRequestCompletionRoutine - ends As you can see I get the error status C000000C for the second ISO Packet. It corresponds to NT_STATUS_TIMER_NOT_CANCELED. Can you please help me to resolve this? "Gopalakrishnan" wrote: > Hi Eliyas, > > I used the sample code in src\kmdf\USBSAMP in the Vista RC1 WDK to > read from isochronous pipe instead of my code. Following is the output from > the driver as soon as the read request is sent, > > UsbSamp: SubRequestCompletionRoutine - begins > UsbSamp: read-write irp failed with status C0000001 > UsbSamp: urb header status C0000B00 > UsbSamp: IsoPacket[0].Length = 0 IsoPacket[0].Status = C0000005 > UsbSamp: IsoPacket[1].Length = 0 IsoPacket[1].Status = C0000005 > UsbSamp: no more pending sub requests > UsbSamp: Total data transferred = 0 > UsbSamp: SubRequestCompletionRoutine Read completed > UsbSamp: SubRequestCompletionRoutine - ends > > My device supports upto Fullspeed only. > > Can you please infer what could be the possible reason for the failure. > > Thanks, > Gopalakrishnan. > > > > "Eliyas Yakub [MSFT]" wrote: > > > Can you dump the IFR log of your driver to see whether the request was > > failed by framework or by the underlying USB stack? > > > > http://www.microsoft.com/whdc/driver/wdf/KMDF-build.mspx > > -- > > -Eliyas > > This posting is provided "AS IS" with no warranties, and confers no rights. > > http://www.microsoft.com/whdc/driver/tips/default.mspx > > > >
From: Eliyas Yakub [MSFT] on 21 Sep 2006 22:14 I asked you to check the messages logged by the framework. Doron's blog describes how to get that. http://blogs.msdn.com/doronh/archive/2006/07/31/684531.aspx -- -Eliyas This posting is provided "AS IS" with no warranties, and confers no rights. http://www.microsoft.com/whdc/driver/tips/default.mspx
From: Tim Roberts on 22 Sep 2006 23:33 Gopalakrishnan <Gopalakrishnan(a)discussions.microsoft.com> wrote: > > In continuation with my last post, the following is the trace message >that I got when I tried to transfer 80 bytes of data from the device to host >using isochronous pipe. I'm a little disappointed that you couldn't figure this one out yourself. The problem is quite clear. >UsbSamp: PerformFullSpeedIsochTransfer Read - begins >UsbSamp: totalLength = 80 >UsbSamp: packetSize = 64 >UsbSamp: PerformFullSpeedIsochTransfer::stageSize = 80 >UsbSamp: PerformFullSpeedIsochTransfer::numSubRequests = 1 >UsbSamp: nPackets = 2 for Irp/URB pair 0 >Sending subRequest 0x7DECEBA8 >UsbSamp: SubRequestCompletionRoutine - begins >UsbSamp: rwContext->Numxfer = 80 >UsbSamp: IsoPacket[0].Length = 40 IsoPacket[0].Status = 0 >UsbSamp: IsoPacket[1].Length = 10 IsoPacket[1].Status = C000000C >UsbSamp: no more pending sub requests >UsbSamp: urb start frame F22B >UsbSamp: Total data transferred = 50 >UsbSamp: SubRequestCompletionRoutine Read completed >UsbSamp: SubRequestCompletionRoutine - ends > > As you can see I get the error status C000000C for the second ISO Packet. >It corresponds to NT_STATUS_TIMER_NOT_CANCELED. No, it doesn't. It corresponds to USBD_STATUS_BUFFER_OVERRUN. See usb.h. The error codes in the packet Status fields are custom to the USB host controller drivers. Your isochronous pipe is configured to deliver 64 bytes per packet. I'm guessing that you didn't TELL the device to deliver only 80 bytes, so it wants to keep delivering full packets of 64 bytes. The host controller sucked up one full packet of 64 bytes ("Length = 40" -- your debug messages switch to hex here). Then, it tried to suck up another full packet. There was only room in your buffer for 16 bytes ("Length = 10"), at which point it would have run over the end of the buffer. Hence, it copied those 16 bytes and returned USBD_STATUS_BUFFER_OVERRUN. You DID get all 80 bytes. >Can you please help me to resolve this? What is your device going to deliver? If it is always delivering full packets of 64 bytes, then the buffers in your URBs must always be a multiple of 64 bytes. -- - Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
First
|
Prev
|
Pages: 1 2 3 4 Prev: WinCE modifications Serial_class to USBser class Next: __readmsr and __writemsr usage |