Re: OHCI IssueBulkTransfer problem

What is really strange is when I run the same driver and test program
under UHCI on a different platform everything works. In fact the USB
monitor trace looks exactly the same.

Tom


MrTom wrote:
The SetClearFeature is never sent out to the device because ResetPipe(
) in usbclient.c does not think the pipe is halted. In fact the
attached device does not appear to be halted because it will continue
to send packet when requested.

Tom


David Liao (MS) wrote:
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




.

Relevant Pages

  • Re: OHCI IssueBulkTransfer problem
    ... David Liao wrote: ... I believe I describe how reset work before. ... The device wants to send a 'one' toggle bit on the lost packet. ... //Pack sent before transfer timeout and received and returned ...
    (microsoft.public.windowsce.platbuilder)
  • Re: OHCI IssueBulkTransfer problem
    ... your description, it looks like it is certainly Data Toggle issue, the ... USB OHCI or SetClrearFeature is send out but your function device ignor it. ... //Pack sent before transfer timeout and received and returned ... When the packet that is lost is sent, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: OHCI IssueBulkTransfer problem
    ... to send packet when requested. ... David Liao wrote: ... USB OHCI or SetClrearFeature is send out but your function device ignor it. ... //Pack sent before transfer timeout and received and returned ...
    (microsoft.public.windowsce.platbuilder)
  • Re: OHCI IssueBulkTransfer problem
    ... Each packet is one or more ascii ... //Pack sent before transfer timeout and received and returned ... // timeout The USB Analyzer shows pack was sent over wire with correct ... This because you are cancelling the transfer, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: OHCI IssueBulkTransfer problem
    ... Toggle bit isn't specified in any state. ... to send packet when requested. ... //Pack sent before transfer timeout and received and returned ... So, after cancelling, you have to reset the pipe in order to ...
    (microsoft.public.windowsce.platbuilder)