[usb] USB1.1 Core Address Assignment Failing. Debugging suggestions?

[Evan Jones <ejones@uwaterloo.ca>]

Hello,

We are using the OpenCores USB1.1 function controller on an Altera APEX 
prototype board to develop a custom USB device. We have the core 
compiled and attached to a Fairchild USB transceiver (pin compatible 
with the Phillips part than Rudy used to test the core). It appears 
like the core is successfully communicating with the host PC, however 
the host PC reports that the address assignment failed. Using Linux, 
the kernel tries to assign an address to the device twice, and both 
times reports the error "Babble", which the linux kernel USB 
documentation describes as:


The amount of data returned by the endpoint was greater than either the 
max packet size of the endpoint or the remaining buffer size.


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). Could it be timing issues? Protocol issues?

The Altera prototype board has a 33.333 MHz clock. The APEX device we 
are using has a PLL component that we are using to multiple the clock 
by 36/25 to get the required 48MHz clock. Could this clock be 
inaccurate, and causing problems? The USB port and transceiver are on a 
daughterboard that is connected to the FPGA using a short (~5cm) IDE 
cable. Could noisy signals on this cable be causing these problems? The 
transmit signals coming from the FPGA are quite gross (lots of ringing) 
but the output of the transceiver looks just as good as the signals 
from the PC. If needed, I can provide schematics of our connections 
from the USB1.1 core to the USB bus, and I can provide the captures 
from the oscilloscope. We have tried everything that we can think of, 
and are looking for suggestions about what to try next.

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 the OS can read the max packet size? Also 
mysterious: The subsequent times that we plug in the device, we see 
this SetAddress request:

SETUP (host -> device address: 0 endpoint: 0)
DATA0 SetAddress (h -> d) (with the address that matches the one 
reported by the kernel)
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. We are starting to get 
frustrated, as it seems that we are so close to getting this to work. 
If we do manage to get the USB1.1 core working, we will provide full 
documentation to the OpenCores project, to make it easier for others in 
the future to implement this core.

Thank you for your time, and thanks to Rudy for providing this core,

Evan Jones

--
Evan Jones: http://www.eng.uwaterloo.ca/~ejones/
"Computers are useless. They can only give answers" - Pablo Picasso

--
To unsubscribe from usb mailing list please visit http://www.opencores.org/mailinglists.shtml