Date: Mon, 9 Jul 2007 21:27:43 -0400 From: "Xiaofan Chen" <xiaofanc@gmail.com> To: "Hans Petter Selasky" <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD Message-ID: <a276da400707091827g48f531fagf6fb20fb4ee5a058@mail.gmail.com> In-Reply-To: <200707091835.50445.hselasky@c2i.net> References: <a276da400704030427g6fcfdc37u43bdf0fd1cd69ea8@mail.gmail.com> <200707051724.30175.hselasky@c2i.net> <a276da400707071725x2b2b8ab3ife6c5459d06042bd@mail.gmail.com> <200707091835.50445.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/9/07, Hans Petter Selasky <hselasky@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? I need to look further but what you mentioned seem to make sense. "*pDst.bRam = _UCPU" seems to clear the buffer. The following are the definitions for for the Buffer Descriptor Status Register. /* Buffer Descriptor Status Register Initialization Parameters */ #define _BSTALL 0x04 //Buffer Stall enable #define _DTSEN 0x08 //Data Toggle Synch enable #define _INCDIS 0x10 //Address increment disable #define _KEN 0x20 //SIE keeps buff descriptors enable #define _DAT0 0x00 //DATA0 packet expected next #define _DAT1 0x40 //DATA1 packet expected next #define _DTSMASK 0x40 //DTS Mask #define _USIE 0x80 //SIE owns buffer #define _UCPU 0x00 //CPU owns buffer FYI: Datasheet of PIC18F2550 USB MCU: http://ww1.microchip.com/downloads/en/DeviceDoc/39632D.pdf bit 7 UOWN: USB Own bit(1) 0 = The microcontroller core owns the BD and its corresponding buffer 1 = SIE owns the BD and its corresponding buffer Note: This bit must be initialized by the user to the desired value prior to enabling the USB module. bit 6 DTS: Data Toggle Synchronization bit(2) 1 = Data 1 packet 0 = Data 0 packet Note: This bit is ignored unless DTSEN = 1 bit 5 KEN: BD Keep Enable bit 1 = USB will keep the BD indefinitely once UOWN is set (required for SPP endpoint configuration) 0 = USB will hand back the BD once a token has been processed bit 4 INCDIS: Address Increment Disable bit 1 = Address increment disabled (required for SPP endpoint configuration) 0 = Address increment enabled bit 3 DTSEN: Data Toggle Synchronization Enable bit 1 = Data toggle synchronization is enabled; data packets with incorrect Sync value will be ignored except for a SETUP transaction, which is accepted even if the data toggle bits do not match 0 = No data toggle synchronization is performed bit 2 BSTALL: Buffer Stall Enable bit 1 = Buffer stall enabled; STALL handshake issued if a token is received that would use the BD in the given location (UOWN bit remains set, BD value is unchanged) 0 = Buffer stall disabled bit 1-0 BC9:BC8: Byte Count 9 and 8 bits The byte count bits represent the number of bytes that will be transmitted for an IN token or received during an OUT token. Together with BC<7:0>, the valid byte counts are 0-1023. What Warner mentioned before might also be correct. On 7/8/07, M. Warner Losh <imp@bsdimp.com> wrote: > : > > I never learned the details, but a client of mine was able to get > : > > fixes from Microchip for their product. The exact problem was that > : > > endpoint stall clearing didn't work for these devices and it was a > : > > firmware bug. > I need to look it up, but I believe that a clear endpoint stall also > resets the toggle, and that was the bug that was tracked down. > FYI: the Firmware source code for PICkit 2, an HID device is here. http://ww1.microchip.com/downloads/en/DeviceDoc/FirmwareV2.10.00.zip I am still in the process of understanding the firmware so I may misunderstand something. But I will try to dig further. Regards, Xiaofan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a276da400707091827g48f531fagf6fb20fb4ee5a058>