On Sat, 14 Apr 2007, John Wojnaroski wrote:
> Alan Stern wrote:
>
> >On Sat, 14 Apr 2007, John Wojnaroski wrote:
> >
> >
> >
> >>Here is a trace of the MS windows program doing it's thing
> >>
> >>Byte 0 = 0x21
> >>Byte 1 = 0x09
> >>Byte 2 = 0x00
> >>Byte 3 = 0x02
> >>Byte 4 = 0x00
> >>Byte 5 = 0x00
> >>Byte 6 = 0x00
> >>Byte 7 = 0x03
> >>Byte 8 = 0x00
> >>
> >>
> >
> >There's something fishy here. This output lists 9 bytes but a control
> >setup packet is supposed to contain only 8 bytes of data. Is it possible
> >that "Byte 2" doesn't belong in there at all?
> >
> >Alan Stern
> >
> >
> >
> >
> >
> Or the last byte, the trace was sent to me by the folks who built the
> chip and ran it on their test setup. It works just fine, well at least
> it works with the test and .dll file they provided. If "byte 2" is
> removed that says the bytes are in reverse order.
I don't know what you mean by "reverse order". They are supposed to be in
little-endian order. Since the original call to USB_CMD (not shown above)
was
USB_CMD( 21 9 2 0 3 ),
I assumed that the "2" and "3" really did mean 2 and 3 -- not 0x200 or
0x300 -- and so the correct sequence of bytes should have been
0x21 0x09 0x02 0x00 0x00 0x00 0x03 0x00
> I have to recompile my kernel, looks like 2.6.9 does not have the usbmon
> code as there is no text file in Doc.... That breaks a few modules I
> have, nothing major, but one more step -- a lot of work for three lousy
> bytes , ahhh, the price of progress ;-)
You'd be a lot better off using a more recent kernel, such as 2.6.20.
> Thanks guys, for the help, good news is I have the usb monitor working.
> here is a bit of output for a control msg
>
>
> de01e2c0 3812071750 S Co:003:00 s 21 09 0200 0000 0003 3 = 021f1f
Note that this byte sequence indicates you did the equivalent of
USB_CMD( 21 9 200 0 3 ),
which is different from what you wrote earlier.
> de01e2c0 3812076624 C Co:003:00 0 3 >
> de01e2c0 3812076741 S Co:003:00 s 01 0b 0000 0000 0000 0
> de01e2c0 3812079623 C Co:003:00 0 0
>
> bad news is the device likes to see a two byte CRC value after the 3
> byte data packet, shown here as "021F1F"
Are you talking about the standard USB CRC? It is added automatically by
the computer's USB host controller at the end of every packet which needs
it.
Or are you talking about some other CRC, something specific to this
particular device? If so then you need to put it there yourself, making
the data packet 5 bytes, not 3.
> looks like I need to talk to the folks at Hagstrom who built the chip to
> see exactly what is possible. If the kernel (devio.c or whatever) does
> not add a CRC value not sure how to "fake it". Trying to add it apriori
> and upping the byte count to 5 doesn't work and returns a Broken pipe msg.
Did you remember to specify the increased length in the call to USB_CMD?
USB_CMD( 21 9 200 0 5 )
> Guess the chip "thinks" three+2, runs the CRC to confirm, and then
> throws it away and acts on the first three bytes if valid.
>
> I played with the byte ordering for the h--- of it with no change, data
> goes out but the chip fails to return a 3 byte response packet
It sounds like you don't really know what the chip wants to receive. It's
going to be hard to make any progress until you can figure that out.
Alan Stern
-------------------------------------------------------------------------
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/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
