libusb usb_interrupt_read hangs under FreeBSD

Hans Petter Selasky hselasky at c2i.net
Thu Jul 5 15:24:35 UTC 2007


On Wednesday 04 July 2007 19:05, Xiaofan Chen wrote:
> > On 4/4/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> > > On Wednesday 04 April 2007 01:55, Xiaofan Chen wrote:
> > > > On 4/3/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> > > > > Hi,
> > > > >
> > > > > I think that your device is broken, and goes bad when it receives a
> > > > > clear-stall request for the interrupt pipe. That is not very
> > > > > uncommon.
> > > >
> > > > Could you be more clearer? I'd like to communicate this problem
> > > > to the firmware developer of PICKit 2 inside Microchip. Thanks.
> > >
> > > The chip does not handle a clear-stall request on the control pipe to
> > > clear-stall on the interrupt pipe. The result is that the interrupt
> > > pipe stops, or at least all buffers are cleared.
> > >
> > > I could be more detailed, but I think the developers will understand
> > > what I mean.
>
> Sorry to dig out this again. I read a bit more on the firmware source code
> and I found the following. Seems a bit dubious. The USB controller used
> is Microchip 18F2550.
>
> Any comments? Thanks in advance.
>

This pre-condition does not always hold:

> *
> * PreCondition:    A STALL packet is sent to the host by the SIE.
> *

Usually the clear-stall is specific to an endpoint, which is stored in the 
lower byte of "wIndex". Where does this "wIndex" end up?

>   if(UEP0bits.EPSTALL == 1)
>   {
>       USBPrepareForNextSetupTrf();        // Firmware Work-Around
>       UEP0bits.EPSTALL = 0;
>   }
>   UIRbits.STALLIF = 0;
> }//end USBStallHandler
>
>

Maybe this code path has never been taken before?

--HPS


More information about the freebsd-usb mailing list