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