Re: OHCI IssueBulkTransfer problem by David
David
Thu Aug 31 12:36:53 CDT 2006
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@intermec.com> wrote in message
news:1156977597.155252.274350@m73g2000cwd.googlegroups.com...
> 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@intermec.com> wrote in message
>> news:1156960905.010409.162890@b28g2000cwb.googlegroups.com...
>> >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@intermec.com> wrote in message
>> >> news:1156793859.539202.180430@m79g2000cwm.googlegroups.com...
>> >> > 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
>> >> >
>> >
>