Re: OHCI IssueBulkTransfer problem
- From: "David Liao \(MS\)" <davli@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Aug 2006 10:36:53 -0700
If you have USB Bus Trace, it would be easier to identify the problem. From
your description, it looks like it is certainly Data Toggle issue, the
ResetPipe suppose to call SetClearFeature to clear ENDPOINT_HALT.
There are two posibility here, one is SetClearFeature is never send out by
USB OHCI or SetClrearFeature is send out but your function device ignor it.
To idenditfy which one, you need USB Bus trace.
David Liao
"MrTom" <thomas.nelson@xxxxxxxxxxxx> wrote in message
news:1156977597.155252.274350@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Here is the order of events. Each packet is one or more ascii
characters.
IssueBulkTransfer( ...USB_IN_TRANSER | USB_SHORT_TRANSFER_OK...)
//Pack sent before transfer timeout and received and returned
IssueBulkTransfer( ...USB_IN_TRANSER | USB_SHORT_TRANSFER_OK...)
//Pack sent before transfer timeout and received and returned
IssueBulkTransfer( ...USB_IN_TRANSER | USB_SHORT_TRANSFER_OK...)
//Pack sent before transfer timeout and received and returned
IssueBulkTransfer( ...USB_IN_TRANSER | USB_SHORT_TRANSFER_OK...)
// Transfer is allowed to timeout
IssueBulkTransfer( ...USB_IN_TRANSER | USB_SHORT_TRANSFER_OK...)
//Pack sent before transfer timeout but nothing is received/returned so
we get another
// timeout The USB Analyzer shows pack was sent over wire with correct
toggle and
// host replied with ACK If a second packet is sent before the timeout
it will be received
// and returned or if we can let it timeout again and it will be
received and returned by
// the next IssueBulkTransfer
IssueBulkTransfer( ...USB_IN_TRANSER | USB_SHORT_TRANSFER_OK...)
//Pack sent and received/returned before transfer timeout
When the packet that is lost is sent, CHW::UsbInterruptThread( ) never
wakes up, in otherwords m_hUsbInterruptEvent is never signaled until
the second packet is sent, yet the USB Analyzer shows the lost packet
was correctly transfered over the wire.
The packet is only lost if the number of received IssueBulkTransfers
before the timeouted out transfer was an odd number.
-Tom
David Liao (MS) wrote:
My opinion, after you have timeout on transfer, Data integrity has gone.
You
need re-sync anyway. This because you are cancelling the transfer, You
don't
know cancel transfer has data or not.
From your describe, either data has get into your canceled transfer or
DATA
toggle is no long sync between the Host and Function.
You probably should take look at how data is present on the USB Bus by
using
USB Bus Analyzer.
David Liao
"MrTom" <thomas.nelson@xxxxxxxxxxxx> wrote in message
news:1156960905.010409.162890@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have tried ResetPipe after a timeout but it has no effect. When we
look at the traffic on the wire with a monitor the data looks to be
transfering with no NAKs and no lost data and the toggle bit looks fine
even when I do not do a ResetPipe.
Tom
David Liao (MS) wrote:
Did you use com client liberay which located at
public\common\oak\drivers\usb\class\common ?
if Yes, did you know after timeout, the transfer will be close
automaticall?. If trasfer closed without completion, it means it
cancel
current driver.
So, after cancelling, you have to reset the pipe in order to sync with
you
usb client side(because of data toggle bit).
David Liao
"MrTom" <thomas.nelson@xxxxxxxxxxxx> wrote in message
news:1156793859.539202.180430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
We are running into a problem with IssueBulkTransfer on the OHCI
stack
when trying to talk with the TI TUSB3410 RS-232 to USB device under
Windows Mobile 5.0.
I do IssueBulkTransfer with USB_IN_TRANSER | USB_SHORT_TRANSFER_OK
flags set. I get the first packet and all packets as long as the
data
keeps coming. As soon as the data pauses and I get a timeout on the
IssueBulkTransfer I may or may not get the next packet.
If I had received an even number of packets before the timeout I
will
not lose data. If I had received an odd number of packets before the
timeout I will lose the first packet after the timeout.
I am testing by connecting the RS-232 end of the device to a
terminal
emulator and I send a single character in each packet.
This works under the UHCI stack on one of our other platforms.
I am wondering if this is the same problem reported here earlier
under
the subject: "OHCI bug in CTransfer". That post ended saying the
problem was fixed in CE6 Beta. I did a diff with the CE6 Beta OCHI
code
and so far I don't see anything obvious that would fix this problem.
Any comments would be greatly appreciated.
Tom
.
- References:
- OHCI IssueBulkTransfer problem
- From: MrTom
- Re: OHCI IssueBulkTransfer problem
- From: David Liao \(MS\)
- Re: OHCI IssueBulkTransfer problem
- From: MrTom
- Re: OHCI IssueBulkTransfer problem
- From: David Liao \(MS\)
- Re: OHCI IssueBulkTransfer problem
- From: MrTom
- OHCI IssueBulkTransfer problem
- Prev by Date: Re: OHCI IssueBulkTransfer problem
- Next by Date: Re: MmMapIoSpace for applications in CE 6.0?
- Previous by thread: Re: OHCI IssueBulkTransfer problem
- Next by thread: Re: OHCI IssueBulkTransfer problem
- Index(es):
Relevant Pages
|
|
