libusb usb_interrupt_read hangs under FreeBSD

[Hans Petter Selasky]

On Saturday 14 July 2007 00:33, Xiaofan Chen wrote:
> On 7/9/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> > Perhaps what happens is that the "*pDst.bRam = _UCPU;"
> > command clears the FIFO
> > contents of the USB interrupt endpoint in addition to clearing the
> > stall!?
> >
> > If the sequence is like this:
> >
> > Write to interrupt endpoint.
> > Reply command is written to FIFO.
> > Clear interrupt endpoint stall.
> > There is no data to read, because the FIFO has been emptied as a part of
> > the stall command.
> >
> > Xiaofan Chen: Could you check the datasheet for the chip that is used,
> > what the stall command actually does?
>
> Sorry that I have three more questions:
> 1) What is the correct method to correctly respond to clear halt feature
> request in the firmware so that it can still recover from the stall?

The USB 2.0 specification is not very clear about what the clear-stall command 
should do. It almost says that this is device dependant.

I think that clear-stall should only clear the data-toggle ! It should not 
clear any buffers. That should be done by a seperate control transfer.

The thing is: If you start a BULK in transfer for example, then you abort this 
transfer, then what should the next data-toogle be? If it is wrong you will 
loose a data-packet without notification! Therefore ugen always clears stall 
first.

According to the USB2.0 specification:

<cite>

· STALL is returned by a function in response to an IN token or after
the data phase of an OUT or in response to a PING transaction (see
Figure 8-30 and Figure 8-38). STALL indicates that a function is
unable to transmit or receive data, or that a control pipe request is
not supported. The state of a function after returning a STALL (for
any endpoint except the default endpoint) is undefined. The host is
not permitted to return a STALL under any condition.  The STALL
handshake is used by a device in one of two distinct occasions. The
first case, known as "functional stall," is when the Halt feature
associated with the endpoint is set. (The Halt feature is specified in
Chapter 9 of this document.) A special case of the functional stall is
the "commanded stall." Commanded stall occurs when the host explicitly
sets the endpoint's Halt feature, as detailed in Chapter 9. Once a
function's endpoint is halted, the function must continue returning
STALL until the condition causing the halt has been cleared through
host intervention.  The second case, known as "protocol stall," is
detailed in Section 8.5.3. Protocol stall is unique to control
pipes. Protocol stall differs from functional stall in meaning and
duration. A protocol STALL is returned during the Data or Status stage
of a control transfer, and the STALL condition terminates at the
beginning of the next control transfer (Setup). The remainder of this
section refers to the general case of a functional stall.

</cite>

>
> 2) For the host, how does it know that the buffer data is still correct if
> the buffer is not cleared?

Clear stall should only clear the data toggle!

You need a second control command to reset the buffers and/or the protocol!

>
> 2) What cause the stall to happen in the first place?

It is either a wrong data-toggle bit or a protocol error. The device can send 
stall at any time!

--HPS