Hi, I think I figured out where the problems came from.
First, the "too little data": > Get configuration (Fails. For some reason, we get only 32 > bytes back instead of 34.) > MPS=8 FA=2 DIR=0 EP=0 SPD=1 LEN=8 > --out-> 80 06 00 02 00 00 22 00 > MPS=8 FA=2 DIR=2 EP=0 SPD=1 LEN=34 COUNT=32 > <--in-- 09 02 22 00 01 01 00 a0 32 > 09 04 00 00 01 03 01 01 00 > 09 21 10 01 00 01 22 41 00 > 07 05 81 03 08 00 00 > > No status transaction follows, as the buffer rounding bit in > the TD is clear. (Lothar, I added the buffer rounding bit > handling to update_td_status()). > > Then timeout follows: > usb 1-1: unable to read config index 0 descriptor/all > usb 1-1: can't read configurations, error -110 What really happens here is the following sequence of packets on the usb bus: sof, about 100us quiescence, in, data1 (1st 8 bytes), ack, in, nack, in, nack, in, nack, in, data0 (2nd 8 bytes), ack, in, nack, in, nack, in, nack, in, data1 (3rd 8 bytes), ack, in, nack, in, nack, in, nack, in, data0 (4th 8 bytes), ack, 150us quiescence, sof and over it is. There was not enough time in the frame to perform more transfers. If I reduced the lsthreshold register's content to 0, I got all the bytes for this transfer. I.e., the last line in the above sequence became in, data0 (4th 8 bytes), ack, in, nack, in, data1 (last 2 bytes), ack, sof but then it failed later in the configuration process, when even more bytes were requested. The "HC does not send off" case: > With one device, I have seen another type of weirdness. The > device is Trendnet's TMR-61U2 card reader (which, again, > works perfectly if attached to my x86 box). For that device, > the failure seems to be that HC just does not send off the > IN transaction. Like here: > > set address (OK) > MPS=8 FA=0 DIR=0 EP=0 SPD=0 LEN=8 > --out-> 00 05 02 00 00 00 00 00 > MPS=8 FA=0 DIR=2 EP=0 SPD=0 LEN=0 > > get device descriptor (Fails, IN transaction not performed) > MPS=8 FA=2 DIR=0 EP=0 SPD=0 LEN=8 > --out-> 80 06 00 01 00 00 08 00 > MPS=8 FA=2 DIR=2 EP=0 SPD=0 LEN=8 COUNT=0 > > The Philips transfer descriptor for this last IN > transaction, read back from the device AFTER HC has reported > via ATLInt that the buffer is processed and ready, is the > following: > > fc00 0808 0808 0002 > > where the leftmost nibble f shows that the HC has not even > tried to perform the IN transaction. In fact what I saw on the USB bus, was this: sof, in, nack, in, nack, ...pattern repeats..., in, nack, 150us quiet, sof and over it is again. I.e., the device was just not yet ready during that particular millisecond. After getting the above packet sequences from the usb bus with a logic analyzer (I have no usb analyzer, but hand-decoding of the NRZI-encoded stream is not that hard), I re-learned that there is this ACTIVE bit in the PTD header and what it really means. Embarrasing, isn't it. I suspected all the time there's something wrong with our hardware or chip configuration and therefore overlooked the sending process. Olav ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
