From owner-freebsd-usb@FreeBSD.ORG Mon Jul 9 16:35:55 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF0F716A46B for ; Mon, 9 Jul 2007 16:35:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 0335A13C447 for ; Mon, 9 Jul 2007 16:35:54 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [212.17.141.53] (account mc467741@c2i.net HELO [10.150.99.181]) by mailfe02.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 543787224; Mon, 09 Jul 2007 18:35:51 +0200 From: Hans Petter Selasky To: "Xiaofan Chen" Date: Mon, 9 Jul 2007 18:35:50 +0200 User-Agent: KMail/1.9.5 References: <200707051724.30175.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707091835.50445.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 16:35:56 -0000 On Sunday 08 July 2007 02:25, Xiaofan Chen wrote: > On 7/5/07, Hans Petter Selasky wrote: > > > > > 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. > > The following is part of the usb firmware from Micrcohip. > > Somehow it masks EP0 in the handler to SET & CLEAR FEATURES > requesrs. Is this the problem? > > if((SetupPkt.bFeature == ENDPOINT_HALT)&& > (SetupPkt.Recipient == RCPT_EP)&& > (SetupPkt.EPNum != 0)) > > > /************************************************************************** >**** * Function: void USBStdFeatureReqHandler(void) > * > * PreCondition: None > * > * Input: None > * > * Output: None > * > * Side Effects: None > * > * Overview: This routine handles the standard SET & CLEAR FEATURES > * requests > * > * Note: None > > *************************************************************************** >**/ void USBStdFeatureReqHandler(void) > { > if((SetupPkt.bFeature == DEVICE_REMOTE_WAKEUP)&& > (SetupPkt.Recipient == RCPT_DEV)) > { > ctrl_trf_session_owner = MUID_USB9; > if(SetupPkt.bRequest == SET_FEATURE) > usb_stat.RemoteWakeup = 1; > else > usb_stat.RemoteWakeup = 0; > }//end if > > if((SetupPkt.bFeature == ENDPOINT_HALT)&& > (SetupPkt.Recipient == RCPT_EP)&& > (SetupPkt.EPNum != 0)) > { > ctrl_trf_session_owner = MUID_USB9; > /* Must do address calculation here */ > pDst.bRam = (byte*)&ep0Bo+(SetupPkt.EPNum*8)+(SetupPkt.EPDir*4); > > if(SetupPkt.bRequest == SET_FEATURE) > *pDst.bRam = _USIE|_BSTALL; > else > { > if(SetupPkt.EPDir == 1) // IN > *pDst.bRam = _UCPU; > else > *pDst.bRam = _USIE|_DAT0|_DTSEN; > }//end if > }//end if > }//end USBStdFeatureReqHandler > 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? --HPS