At 02:23 PM 12/6/01 -0800, David Brownell wrote: >Bitstuff: the USB protocol restricts how many ones/zeros may >be consecutively sent down the wire. Details in the spec, the >basic idea is (as I recall) to make sure that no data can cause >a signal pattern that looks much like the ones used to delimit >packets, frames, and such.
Not exactly, the bit stuffing is to maintain 12 MHz USB bus clock synchronization. After 6 zeros, a 1 bit is stuffed into the send line (always-even if the next bit is a one). On reception the deserializer will always assume that it will get a 1 bit after seeing 6 zeros. If not it is a bit stuffing error. Both host and device are supposed to check this. They will resend if detected-and its detection almost always handled in hardware. >PID problem: PID is a field in the USB packet. USB_PID_* >in <linux/usb.h> ... examples are IN, OUT, DATA0, DATA1. >I don't have time to track this down further (look at the OHCI >and USB specs, and debug!) but if the HC got the wrong PID, >or an illegal one, that should appear. A PID is a one byte token such as ACK,NAK,IN,SETUP etc. Data0 and Data1 packets are checked with a 16 bit crc. INs, OUTs, and SETUPs contain other info like device address and endpoint, so they are checked by a 5 bit crc. Lone tokens like ACK, NAK, STALL don't have a crc and only consume 8 bits of bus bandwidth, so they have to be checked too. The way they are checked is that each PID is defined in a nibble (so only 15 max pids), followed by the same nibble written backward, so 0xa5 or 0x18 etc. is the PID code. In this way hosts and devices can verify that tokens are ok or if a retry is needed. These kinds of errors along with babble (unexpected bits on the USB data lines), usually indicate bad cables, or bad hardware. One other thing, I keep seeing people write about the PCI bandwidth hogging option in the uhci host controller drivers. The idea is if you get a NAK from a bulk device in a frame, keep asking it in case it gets ready in the rest of the current frame. This causes a torrent of INs or OUTs on the USB bus and apparently keeps the PCI bus busier too. The funny thing is I have never seen any device that NAKs in a frame be able to respond again in that same frame. Why would they? Another popular OS (tm) would never ask after seeing a NAK, so it would be pointless effort on the device's part. Has anyone seen (with a bus analyzer like CATC) a device respond in the same frame in which in NAKed? I think this attempt at optimizing the USB bus bandwidth should be removed from the kernel, it just confuses people. ~Steve >- Dave > > >----- Original Message ----- >From: "Matthew Dharm" <[EMAIL PROTECTED]> >To: "David Brownell" <[EMAIL PROTECTED]> >Cc: "Björn Stenberg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Thursday, December 06, 2001 2:05 PM >Subject: Re: [linux-usb-devel] Error -71 (fwd) > >What, exactly, is a "bitstuff error" and "PID problems"? > >Matt > >On Thu, Dec 06, 2001 at 01:41:05PM -0800, David Brownell wrote: > > > Error -71 is EPROTO, but why do I get it all of a sudden? The only > places I > > > see it returned in the code are in uhci.c and usb-uhci.c. But this is > OHCI... > > > > The current "usb-ohci.c" uses the <linux/usb.h> USB_ST_* macros, > > which use EPROTO for USB_ST_BITSTUFF and in one other > > place that OHCI doesn't trigger. > > > > In drivers/usb/usb-ohci.h I see USB_ST_BITSTUFF for three errors > > that the hardware reports -- bitstuffing errors and PID problems. > > > > Unclear why you get it "all of a sudden". > > > > - Dave > > > > > > > >_______________________________________________ >[EMAIL PROTECTED] >To unsubscribe, use the last form field at: >https://lists.sourceforge.net/lists/listinfo/linux-usb-devel Regards, Steve __________________________________________ Steve Calfee -- embedded systems consultant [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
