Re: OHCI IssueBulkTransfer problem

My opinion, It all determine what happens on the bus and hardware
implementation.
I believe I describe how reset work before.
1. Reset Pipe will calls ClearHaltedFlags to clear Halt and Toggle bit on
this pipe.
2. It will Call SetOrClearFeature(clear, endpoint halt) (Send control data
to device) to clearn halt bit and toggle bit on device.
ResetPipe does not device, it only reset the endpoint (pipe)

"MrTom" <thomas.nelson@xxxxxxxxxxxx> wrote in message
news:1157477363.017004.227620@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
That is interesting. Would the reset pipe send anything out to the
device? Nothing is sent to the device when using the UHCI stack and as
I stated everything works with the UHCI stack. If what you are saying
is true, then working with the UHCI stack is accidental.

Also, would ResetPipe set the stack back to waiting for a zero toggle
bit? The device wants to send a 'one' toggle bit on the lost packet.
This would imply to me that ResetPipe must also reset the device.

Tom

David Liao (MS) wrote:
My opinion,
I don't believe this is the bug. After you canceling the Transfer, The
Toggle bit isn't specified in any state. So you have to issue reset to
this
resolve this.
The Common library only reset pipe when pipe is Stall. But, you can call
reset function directly. by lpUSBPtr->lpResetPipe..

David Liao

"MrTom" <thomas.nelson@xxxxxxxxxxxx> wrote in message
news:1157405777.245197.13550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
We have found what appears to be a bug in the OHCI stack. Our change
fixes the problem and packets are no longer lost.

In CQueuedPipe::AbortTransfer( )

This line of code destroys the toggle bit which lives in the low bits
of paTdQueueHead.

// We need to complete the transfer ourselves
m_pED->paTdQueueHead = m_pED->paTdQueueTail =
GetTDQueueHeadPhys();

by saving and restoring the toggle bit packets are no longer lost.

//Note: This code copied from
CQueuedPipe::CheckForDoneTransfers( )
DWORD toggleCarry = m_pED->bfToggleCarry; // this field is
actually part of QueueHead
...
// We need to complete the transfer ourselves
m_pED->paTdQueueHead = m_pED->paTdQueueTail =
GetTDQueueHeadPhys();

//Note: This code copied from
CQueuedPipe::CheckForDoneTransfers( )
// We need to repair the toggle bit because the previous
line zero'd it
// Do this BEFORE skip is turned off, while we still "own"
the ED
if (GetType () == TYPE_CONTROL)
m_pED->bfToggleCarry = 1;
else
m_pED->bfToggleCarry = toggleCarry;

Tom

MrTom wrote:
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
    ... 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)
  • 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
    ... I stated everything works with the UHCI stack. ... 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)
Loading