[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[usb] Usb1.1: Minor inconsistent behaviour
Hello,
We've been testing out USB1.1 function controller on our Altera FPGA,
and we have noticed two unusual behaviours. These behaviours are
reproducible on multiple operating systems (MacOSX, Linux 2.4, Windows
2000) and multiple machines. We believe that they are either bugs in
the hardware, or bugs in our configuration. Does anyone have any
suggestions for how we might resolve these two issues? Neither are very
serious, but they are puzzling.
We are using Altera's Quartus 2 software with an APEX20KE FPGA.
#1. Multiple "SET_CONFIGURATION" can cause the device to stop reponding
correctly. We have a device configured as a loopback: It has one OUT
endpoint that is connected to a FIFO, and an IN endpoint that is
connected to the same FIFO. Our test program locates the device and
then uses SET_CONFIGURATION to enable to "loop back" configuration. If
we run this program a number of times, eventually (normally 3 - 5
times) the send operation will start completing successfully, but
reading for the OUT endpoint will return no data. If we reconnect the
device, it works again. Any ideas? This is not very serious, as it has
a simple work around: Simply call SET_CONFIGURATION once and only once
for the device. Perhaps performing a USB reset before our test program
quits would also work around this issue.
#2. The device is reading the string configuration from the wrong part
of the ROM. We were having difficulty getting the string descriptors to
work, so we modified the Linux kernel to print the data that it was
reading. Using this, we were able to determine where in the ROM our
data was being read from by filling the string descriptors in the ROM
with the address of each byte. It appears to us that the device is
reading from the wrong address in the ROM. I've labelled the lines
where we think it should read from, and where it actually reads from.
section from usb1_defines.v:
`define ROM_SIZE0 7'd018 // Device Descriptor Length
`define ROM_SIZE1 7'd032 // Configuration Descriptor Length
`define ROM_SIZE2A 7'd004 // Language ID Descriptor Start Length
`define ROM_SIZE2B 7'd010 // String Descriptor Length
`define ROM_SIZE2C 7'd010 // for future use
`define ROM_SIZE2D 7'd010 // for future use
`define ROM_START0 7'h00 // Device Descriptor Start Address
`define ROM_START1 7'h12 // Configuration Descriptor Start Address
`define ROM_START2A 7'h32 // Language ID Descriptor Start Address
`define ROM_START2B 7'h36 // String Descriptor Start Address
`define ROM_START2C 7'h40 // for future use
`define ROM_START2D 7'h4a // for future use
section from usb1_rom.v:
// ====================================
// ===== String Descriptor Lang ID=====
// ====================================
7'h32: dout <= #1 8'd04; // this descriptor length IT SHOULD READ
THE LANG IDS STARTING HERE
7'h33: dout <= #1 8'd03; // descriptor type
7'h34: dout <= #1 8'd09; // Language ID 0 low byte
7'h35: dout <= #1 8'd04; // Language ID 0 high byte
// ====================================
// ===== String Descriptor 0 =====
// ====================================
7'h36: dout <= #1 8'd020; // this descriptor length
7'h37: dout <= #1 8'd03; // descriptor type
7'h38: dout <= #1 "0";
7'h39: dout <= #1 " ";
7'h3a: dout <= #1 "g";
7'h3b: dout <= #1 "n";
7'h3c: dout <= #1 "i";
7'h3d: dout <= #1 8'd04;
7'h3e: dout <= #1 8'd03;
7'h3f: dout <= #1 8'd09;
// ====================================
// ===== String Descriptor 1 =====
// ====================================
7'h40: dout <= #1 8'd04; // this descriptor length
7'h41: dout <= #1 8'd03; // descriptor type
7'h42: dout <= #1 "1";
7'h43: dout <= #1 " ";
7'h44: dout <= #1 "g";
7'h45: dout <= #1 "n";
7'h46: dout <= #1 "i";
7'h47: dout <= #1 8'd04; // BUT IT ACTUALLY READS THE LANGUAGE ID
TABLE STARTING HERE
7'h48: dout <= #1 8'd03;
7'h49: dout <= #1 8'd09;
// ====================================
// ===== String Descriptor 2 =====
// ====================================
7'h4a: dout <= #1 8'd04; // this descriptor length
7'h4b: dout <= #1 8'd03; // descriptor type
7'h4c: dout <= #1 "2";
7'h4d: dout <= #1 " ";
7'h4e: dout <= #1 "g";
7'h4f: dout <= #1 "n";
7'h50: dout <= #1 "i";
7'h51: dout <= #1 8'h51;
7'h52: dout <= #1 "t";
7'h53: dout <= #1 "S";
--
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