BTW I just asked on another thread, do the smart pins -1/-2/-3 wrap from P0 to P63 etc. ie I could use smart pins P0 & P1 both with -2 to access actual P62 & P63 pins respectively ??? If this works then this would solve my problem.
Was playing with this for an hour this morning with my USB sniff setup with low speed USB joystick and still not getting anywhere.
Then, I made a mistake and reversed DP and DM wires and it suddenly started working!
I there any chance that Chip has DP being D- and DM being D+?
Don't like my odds when it's one of Chip or me being backwards though...
Still looking at this, but it still looks like docs and sample code have DM and DP reversed...
I think I see now that J and K states are reversed between low and high speed devices. This might be my issue...
Darn it, my wires were backwards. Learning some lessons here... Didn't appreciate that signaling was reversed between low speed and high speed modes... Painfully obvious now...
I'm very confused. I'm pretty sure it's working though.
I see an IN command then DATA1 response then ACK.
But, I can't figure out yet what order the bits are supposed to be in...
For example, Wikipedia says ACK is %0100 1011 transmitted LSB first.
This is supposed to represent a PID of %0010 with MSB first and it's inverse.
If I reverse my received bits, I see $4B, which might agree with Wikipedia?
But, looking at "USB made simple", they show ACK as $D2, which is the non reversed version.
I'm very confused. I'm pretty sure it's working though.
I see an IN command then DATA1 response then ACK.
But, I can't figure out yet what order the bits are supposed to be in...
For example, Wikipedia says ACK is %0100 1011 transmitted LSB first.
This is supposed to represent a PID of %0010 with MSB first and it's inverse.
If I reverse my received bits, I see $4B, which might agree with Wikipedia?
But, looking at "USB made simple", they show ACK as $D2, which is the non reversed version.
I don't know. I think I have the signalling working right. At least I can send and receive the same data stream, with bit stuff and unstuff. Every packet must begin with $80, which is received as SOP.
If I reverse my received bits, I see $4B, which might agree with Wikipedia?
But, looking at "USB made simple", they show ACK as $D2, which is the non reversed version.
Does not a real device , trump any web page ? (which could easily conflate value and content)
Did Chip check this with a real USB device yet, or only self-linked ?
Software packages for automated compliance test are available for Ethernet 10BASE-T and 100BASE-T (Option ET3), and USB 2.0 (Option USB) physical-layer devices. These software packages enable you to conduct testing using the standard's specified compliance tests.
The non-reversed version of the IN packet is $69, $9B, $70.
The CRC-5 result would be %1000
Can't make that work
Reversed version of IN packet is $96,$D9,$0E.
The CRC-5 result would be %01110
This one seems to work
Starting from %11011001000
First do an xor with %11111 on the left side
Then xor with polynomial %100101 from left to right.
Come out with remainder of %10001
Invert that to get %01110, which matches last 5 bits in reversed IN packet...
The non-reversed version of the IN packet is $69, $9B, $70.
The CRC-5 result would be %1000
Can't make that work
Reversed version of IN packet is $96,$D9,$0E.
The CRC-5 result would be %01110
This one seems to work
Starting from %11011001000
First do an xor with %11111 on the left side
Then xor with polynomial %100101 from left to right.
Come out with remainder of %10001
Invert that to get %01110, which matches last 5 bits in reversed IN packet...
That's good! Does it look like the smart pin needs to do any bit reversals?
At this moment it seems like it would be better with each byte bit reversed. But, I've been backwards many times today, so don't feel too confident yet...
At this moment it seems like it would be better with each byte bit reversed. But, I've been backwards many times today, so don't feel too confident yet...
Does the 11b frame number inc each time ? - that would give another check.
but the PID is a puzzle ? http://www.usbmadesimple.co.uk/ums_3.htm
gives
SOF(3:0) 0101b (send LSB first) PID0.PID1.PID2.PID3.\PID0.\PID1.\PID2.\PID3
expect to see 1010_0101 for SOF frame ?
but above is suggesting one of ?
NYET 0110b
or
IN 1001b
to choose from ?
So, what I think happens with this joystick is that every so often the PC sends an IN packet, the joystick responds with a DATA1 packet (presumably with state of buttons and stick) and then the PC responds with ACK.
I'm liking the reversed data because the 5-bit CRC calc on the IN packet's 11-bit payload (7-bit address, 4-bit address) comes out right.
Also, the PID byte matches Wikipedia when reversed.
So, what I think happens with this joystick is that every so often the PC sends an IN packet, the joystick responds with a DATA1 packet (presumably with state of buttons and stick) and then the PC responds with ACK.
So there is no 1ms USB polling tick ?
I thought that was always there on connected devices ? or is this joystick different ?
I'm not seeing that. I think that is for devices that go dormant like a thumbdrive or something maybe. Just a way to see that device is still ticking... I imagine that HID devices just get polled with IN command at regular intervals...
I think I've made a lot of progress today. Feel close to understanding USB for the first time.
Might be a while before I can do anything useful though...
Below is snooping the real USB LS bus when plugging in a MS Keyboard which is LS.
I used the attached P1 program with a 6MHz xtal.
CRC is correctly calculated. When the CRC is applied to the CRC as well, the result is zero.
There is a diagram of the connections in the code.
So, what I think happens with this joystick is that every so often the PC sends an IN packet, the joystick responds with a DATA1 packet (presumably with state of buttons and stick) and then the PC responds with ACK.
So there is no 1ms USB polling tick ?
I thought that was always there on connected devices ? or is this joystick different ?
So, what I think happens with this joystick is that every so often the PC sends an IN packet, the joystick responds with a DATA1 packet (presumably with state of buttons and stick) and then the PC responds with ACK.
So there is no 1ms USB polling tick ?
I thought that was always there on connected devices ? or is this joystick different ?
I believe in low-speed mode, you need to sense an EOP, since that's the keep-alive signal.
There is probably a logical problem with the current smart pin USB mode, where only an SOP clears an EOP. I need to have a full 7+ clock J (IDLE) state clear EOP so that you can see it again on the low-speed keep-alive EOP signal.
From USB 2.0 spec.
"8.1 Byte/Bit Ordering
Bits are sent out onto the bus least-significant bit (LSb) first, followed by the next LSb, through to the most- significant bit (MSb) last. In the following diagrams, packets are displayed such that both individual bits and fields are represented (in a left to right reading order) as they would move across the bus.
Multiple byte fields in standard descriptors, requests, and responses are interpreted as and moved over the bus in little-endian order, i.e., LSB to MSB."
So on the wire, an IN token should be sent as :
(first bit ->) 10010110 (<-last bit), representing 69hex in the actual read byte.
That lines up with what Cluso seems to have collected off the bus in his data above.
I believe in low-speed mode, you need to sense an EOP, since that's the keep-alive signal.
I found this detail "The Start of Frame packet is sent every 1 ms on full speed links.
The frame is used as a time frame in which to schedule the data transfers which are required."
So yes, it seems like that is on FS, but not on LS.
I know a number of MCUs these days rely on that 1ms cadence to lock (auto-trim) their RC oscillators to the USB speed.
They are all FS devices.
I think the P2 cannot quite do that type of RC lock, as it lacks the trim choice on RC-Osc, and would need a USB capture method to sense that 1ms cadence.
Crystals, or better resonators, would be able to meet USB tolerance specs, without lock.
Think above is right...
So then, the current output is in correct order but needs interpretation for token packets...
IN command is followed by 7 bits of address, sent LSB first, then 4 bits of endpoint, sent LSB first, then 5 bits of CRC also sent LSB first. The smartpin is packaging these into two bytes and reversing them bitwise.
At least, that's my current understanding, need to double check with real data if CRC is sent LSB first or MSB first. Unfortunately, my joystick IN winds up with CRC of %01110, which is it's own inverse...
Starting to make sense maybe. PID for ACK is %0010. This is sent as 4-bits with LSB first, then the inverse %1101 is sent with LSB first. Smartpin reverses the byte bitwise and gets $D2. This matches "USB made simple" site. The Wikipedia page manages to make this very confusing to me somehow...
Comments
Was playing with this for an hour this morning with my USB sniff setup with low speed USB joystick and still not getting anywhere.
Then, I made a mistake and reversed DP and DM wires and it suddenly started working!
Now, need to figure out how I messed that up...
Don't like my odds when it's one of Chip or me being backwards though...
Still looking at this, but it still looks like docs and sample code have DM and DP reversed...
I think I see now that J and K states are reversed between low and high speed devices. This might be my issue...
Darn it, my wires were backwards. Learning some lessons here... Didn't appreciate that signaling was reversed between low speed and high speed modes... Painfully obvious now...
It appears that the Smartpin data receiver output is reversed. So, we need to bitwise reverse it before use.
I'm not quite clear on transmitter... Sounds like you don't have to reverse that.
So, do I have things backwards, or not? Anything is possible.
I see an IN command then DATA1 response then ACK.
But, I can't figure out yet what order the bits are supposed to be in...
For example, Wikipedia says ACK is %0100 1011 transmitted LSB first.
This is supposed to represent a PID of %0010 with MSB first and it's inverse.
If I reverse my received bits, I see $4B, which might agree with Wikipedia?
But, looking at "USB made simple", they show ACK as $D2, which is the non reversed version.
I don't know. I think I have the signalling working right. At least I can send and receive the same data stream, with bit stuff and unstuff. Every packet must begin with $80, which is received as SOP.
From everything I read, data is sent LSB-first. There is one exception, I believe, and I think it has to do with one of the CRCs.
Does not a real device , trump any web page ? (which could easily conflate value and content)
Did Chip check this with a real USB device yet, or only self-linked ?
Does that mean self-linked only ?
At least this is easy enough to fix
Hopefully, that will tell me if I have the right order...
I found slide 46 in this series
http://www.slideshare.net/PREMALGAJJAR/usb-protocol
- that should make checking decode of the standard 1ms USB idle traffic easy ?
Does that work ?
I also see on this page
http://www2.tek.com/cmswpt/psdetails.lotr?ct=PS&cs=psu&ci=17742&lc=ES-MX
images like
http://www2.tek.com/cmsrep/psrep/img/17742/A002_8989-L.jpg
and even this mention ( sounds like $$?)
Software packages for automated compliance test are available for Ethernet 10BASE-T and 100BASE-T (Option ET3), and USB 2.0 (Option USB) physical-layer devices. These software packages enable you to conduct testing using the standard's specified compliance tests.
This was with the reversed version of the receiver output.
Used the procedure described here for the CRC: http://www.michael-joost.de/crc5check.pdf
(not the code, just the procedure).
The non-reversed version of the IN packet is $69, $9B, $70.
The CRC-5 result would be %1000
Can't make that work
Reversed version of IN packet is $96,$D9,$0E.
The CRC-5 result would be %01110
This one seems to work
Starting from %11011001000
First do an xor with %11111 on the left side
Then xor with polynomial %100101 from left to right.
Come out with remainder of %10001
Invert that to get %01110, which matches last 5 bits in reversed IN packet...
That's good! Does it look like the smart pin needs to do any bit reversals?
I think that 'reversal needed' is correct, I get
0b 0110 1001 _ 1001 1011 011 _ 1 0000
0b 1001 0110 _ 1101 1001 000 _ 0 1110
Does the 11b frame number inc each time ? - that would give another check.
but the PID is a puzzle ?
http://www.usbmadesimple.co.uk/ums_3.htm
gives
SOF(3:0) 0101b (send LSB first) PID0.PID1.PID2.PID3.\PID0.\PID1.\PID2.\PID3
expect to see 1010_0101 for SOF frame ?
but above is suggesting one of ?
NYET 0110b
or
IN 1001b
to choose from ?
I'm liking the reversed data because the 5-bit CRC calc on the IN packet's 11-bit payload (7-bit address, 4-bit address) comes out right.
Also, the PID byte matches Wikipedia when reversed.
Been looking at this all day because $96 (or maybe $69) is the IN token command...
So there is no 1ms USB polling tick ?
I thought that was always there on connected devices ? or is this joystick different ?
Might be a while before I can do anything useful though...
I used the attached P1 program with a 6MHz xtal.
CRC is correctly calculated. When the CRC is applied to the CRC as well, the result is zero.
There is a diagram of the connections in the code.
I believe in low-speed mode, you need to sense an EOP, since that's the keep-alive signal.
There is probably a logical problem with the current smart pin USB mode, where only an SOP clears an EOP. I need to have a full 7+ clock J (IDLE) state clear EOP so that you can see it again on the low-speed keep-alive EOP signal.
"8.1 Byte/Bit Ordering
Bits are sent out onto the bus least-significant bit (LSb) first, followed by the next LSb, through to the most- significant bit (MSb) last. In the following diagrams, packets are displayed such that both individual bits and fields are represented (in a left to right reading order) as they would move across the bus.
Multiple byte fields in standard descriptors, requests, and responses are interpreted as and moved over the bus in little-endian order, i.e., LSB to MSB."
So on the wire, an IN token should be sent as :
(first bit ->) 10010110 (<-last bit), representing 69hex in the actual read byte.
That lines up with what Cluso seems to have collected off the bus in his data above.
I found this detail
"The Start of Frame packet is sent every 1 ms on full speed links.
The frame is used as a time frame in which to schedule the data transfers which are required."
So yes, it seems like that is on FS, but not on LS.
I know a number of MCUs these days rely on that 1ms cadence to lock (auto-trim) their RC oscillators to the USB speed.
They are all FS devices.
I think the P2 cannot quite do that type of RC lock, as it lacks the trim choice on RC-Osc, and would need a USB capture method to sense that 1ms cadence.
Crystals, or better resonators, would be able to meet USB tolerance specs, without lock.
So then, the current output is in correct order but needs interpretation for token packets...
IN command is followed by 7 bits of address, sent LSB first, then 4 bits of endpoint, sent LSB first, then 5 bits of CRC also sent LSB first. The smartpin is packaging these into two bytes and reversing them bitwise.
At least, that's my current understanding, need to double check with real data if CRC is sent LSB first or MSB first. Unfortunately, my joystick IN winds up with CRC of %01110, which is it's own inverse...
Starting to make sense maybe. PID for ACK is %0010. This is sent as 4-bits with LSB first, then the inverse %1101 is sent with LSB first. Smartpin reverses the byte bitwise and gets $D2. This matches "USB made simple" site. The Wikipedia page manages to make this very confusing to me somehow...
I think the key question is:
Does data byte usage, (as in code loops), require manual bit-reversal ?
If yes, then the USB HW should change to save the cycles and code.
If no, then USB HW is ok ?