[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [usb] Usb1.1: Minor inconsistent behaviour



On Sun, 2003-07-06 at 07:32, Evan Jones wrote:
> 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.

Strange. This is not supported at all in the original code.
All it does is setting an internal flag ("configured") which
is never used.

Could it be the host is waiting for some sort of a response
which he is not getting and marking the device as "bad" ?

Or may be it reads that the device is already configured and
fails because it is configured already ?

> #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.

Can you state the exact commands that are being issued with
all the parameters, so I can check that in the test bench ?

Actually, why don't you try to read the strings in the test
bench. Should be easy to modify it and add the exact commands
with the exact same parameters as you see from the host to
the bench. If you can show in the test bench that it is
failing - I can fix it !

Email me the modified test bench and I'll take a look.

Cheers, 
rudi               
--------------------------------------------------------
www.asics.ws  --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores

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