|
Message
From: Evan Jones <ejones@u...>
Date: Mon, 2 Jun 2003 11:15:00 -0400
Subject: [usb] USB1.1 Core Address Assignment Failing. Debugging suggestions?
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
|
 |
Browse
