Does anyone have any pointers about where I can look up information on how the Linux USB stack (in the 2.4 kernels) initializes and assigns a new device? I'm doing some debugging on a USB device that we have built using the OpenCores USB1.1 controller (http://www.opencores.org/projects/usb1_funct/), and I can't quite figure out what is going wrong. Linux reports "could not assign address: Error -75 (babble)", but I'm trying to figure out where exactly this error comes from. Is there any way that I can get MORE debugging output out of the USB stack, besides just the "USB debugging" kernel option?
I'm using Linux 2.4.20 (benh kernel tree, since my laptop is a Powerbook) with an OHCI USB controller. When we connect the device, linux tries to assign it an address twice, and then quits. It always fails with -75. Looking at the USB bus with the oscilloscope, it appears that the host and the device are talking (we can see packets go back and forth, and the host ACKs our transmissions). Any suggestions about what exactly might be causing the BABBLE problem? Are there any software tools for examining the data on the bus that is easier than decoding the packets manually on the oscilloscope (we are students, we don't have a logic analyser). Our cable is very short (about 20 cm) and the signals look pretty clean on the USB bus. Could it be timing issues? Protocol issues? We think that the USB function controller is correct, since it has been used by others for working devices.
The first time we connect the device we seem to get this sequence of packets. I need to go back into the lab and verify my notes, but I believe this to be correct:
SETUP (host -> device address: 0 endpoint: 0) DATA0 GetDescriptor (h -> d) ACK (d - > h)
... ~ 1ms later:
SOF (h - > d) IN (h -> d addr: 0 endpoint: 0) DATA1 (d -> h) -- contains 0x0000 then the 2 bytes CRC ACK (h -> d)
... ~1ms later:
SOF (h->d) OUT (h->d) addr: 0 endpoint: 0) DATA1 (h->d) -- contains no data, and the CRC ACK (d->h)
This is mysterious: Shouldn't the device send back the first 8 bytes of the descriptor, so Linux can read the max packet size? Where in the Linux USB code does the kernel do this initial read? In usb_new_device() (usb.c:2204) I see that "setAddress" gets called, and I see the following comment which indicates that the kernel DOES this read. But where does this read happen? To my minimal knowledge in tracing the call to usb_set_address(), it doesn't look like that function reads the device descriptior. Does it happen BEFORE usb_new_device()?
/* USB v1.1 5.5.3 */
/* We read the first 8 bytes from the device descriptor to get to */
/* the bMaxPacketSize0 field. Then we set the maximum packet size */
/* for the control pipe, and retrieve the rest */
dev->epmaxpacketin [0] = 8;
dev->epmaxpacketout[0] = 8;err = usb_set_address(dev);
Also mysterious: The subsequent times that we plug in the device, we see the SetAddress request. How does Linux know that it already tried to "GetDescriptor". Or does it? Or did I screw up my notes somewhere?
SETUP (host -> device address: 0 endpoint: 0) DATA0 SetAddress (h -> d) ACK (d - > h)
... ~ 1ms later:
SOF (h - > d) IN (h -> d addr: 0 endpoint: 0) DATA1 (d -> h) -- contains 0x0000 then the 2 bytes CRC ACK (h -> d)
~1ms later the bus seems to get reset (goes low for a long time). What went wrong? Isn't this a correct address assignment sequence?
Thank you for any help that you can provide,
Evan Jones
-- Evan Jones: http://www.eng.uwaterloo.ca/~ejones/ "Computers are useless. They can only give answers" - Pablo Picasso
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
