Alan Stern wrote: >On Mon, 16 Apr 2007, John Wojnaroski wrote: > > > >>OK, attached is a log report. Not all that conversant in analyzing >>the log. about the only item I note is the order of the last two bytes >>defining the packet size; SnoopyPro shows 0300 under Windows and usbmon >>shows 0003 under Linux for the control msg. >> >> > >You are referring to URB #9 in the Windows log, right? It shows: > > SetupPacket > 0000 21 09 00 02 00 00 03 00 > > TransferBuffer: 0x00000003 (3) length > 0000: 02 ff ff > > > >>Significant?? Or just a formatting artifact? >> >> >> >>>de9ab1c0 1992901010 S Co:003:00 s 21 09 0002 0000 0003 3 = 020202 >>>de9ab1c0 1992905882 C Co:003:00 0 3 > >>> >>> > >It is indeed significant. The Windows program has wValue set to 0x0200 >and your Linux program has it set to 0x0002. That could be the source of >all your problems right there. > > > Hmm, now I'm puzzled. Does the byte order actually depict the sequence of the bits sent by the OS? Is this a difference in bigendian/littleendian digits? If so, I goofed, so on to the fix and next step.
Excerpt from the usbmon.txt in ../Linux/Documentaton/usb <<<<<<<<<<<<<<<<, - Setup packet, if present, consists of 5 words: one of each for bmRequestType, bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. These words are safe to decode if Setup Tag was 's'. Otherwise, the setup packet was present, but not captured, and the fields contain filler. >>>>>>>>>>>>>>>>. Here is the usbmon report when I set the wValue to 0x0200 df99e540 2476601557 S Co:002:00 s 21 09 0200 0000 0003 3 = 020202 df99e540 2476606432 C Co:002:00 0 3 > so, that now matches the URB #9 from the SNoopyPro report under windows; bmRequestType = 21 bRequest = 09; wValue = 0x0200 wIndex = 0x0000 wLength = 0x0003 according to the description cited above. And with the "s" that would indicate the packet was captured, but still not getting a response from the device..... Just for completness, here is a series of four frames for each call to the control msg. df99e540 2476601557 S Co:002:00 s 21 09 0200 0000 0003 3 = 020202 df99e540 2476606432 C Co:002:00 0 3 > df99e540 2476606551 S Co:002:00 s 01 0b 0000 0000 0000 0 df99e540 2476609431 C Co:002:00 0 0 df99e540 2478577426 S Co:002:00 s 00 09 0001 0000 0000 0 df99e540 2478580115 C Co:002:00 0 0 df99e540 2478580265 S Co:002:00 s 01 0b 0000 0000 0000 0 df99e540 2478583113 C Co:002:00 0 0 df99e540 2478583236 S Co:002:00 s 21 09 0200 0000 0003 3 = 020202 Well, I'll keep beating on this problem. Might even learn a few things in the process ;-) John ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
