USB Testing
Cluso99
Posts: 18,069
in Propeller 2
Thought this should have its own thread.
I am not quite sure where to start.
These are some things I think will help with the testing...
1. Some form of data logging (logic analyser style)
Need to sample the USB bus (2 bits) at 12MHz = 83.3ns which is 4 clocks at 96MHz.
While oversampling is ideal, this should get us somewhere in the meantime.
How to achieve this ???
(a) Use a P1 (rather difficult to record a long length of data)
My RamBlade might be able to do this by storing the sample bits straight into the SRAM which would give 512K samples.
Perhaps use Peter's Splat (modified) to then display the samples.
(b) Use an FPGA board
Use a modified P1V to store the data. Could make instructions to aid the storage. Limited to cog/hub memory.
Use P2 code (2x faster) to store data into cog/hub.
Either could use an external 512KB SRAM (I have a suitable board - my MemBlade)
(c) Use an FPGA board and P2 smart pins to read the data and store the "bytes" as they are read in.
2. PC with USB Analyser software
I seem to recall that there is some software that can be used to monitor the USB Driver. Need more research.
Any other ideas??? Or comments on the above???
I am not quite sure where to start.
These are some things I think will help with the testing...
1. Some form of data logging (logic analyser style)
Need to sample the USB bus (2 bits) at 12MHz = 83.3ns which is 4 clocks at 96MHz.
While oversampling is ideal, this should get us somewhere in the meantime.
How to achieve this ???
(a) Use a P1 (rather difficult to record a long length of data)
My RamBlade might be able to do this by storing the sample bits straight into the SRAM which would give 512K samples.
Perhaps use Peter's Splat (modified) to then display the samples.
(b) Use an FPGA board
Use a modified P1V to store the data. Could make instructions to aid the storage. Limited to cog/hub memory.
Use P2 code (2x faster) to store data into cog/hub.
Either could use an external 512KB SRAM (I have a suitable board - my MemBlade)
(c) Use an FPGA board and P2 smart pins to read the data and store the "bytes" as they are read in.
2. PC with USB Analyser software
I seem to recall that there is some software that can be used to monitor the USB Driver. Need more research.
Any other ideas??? Or comments on the above???
Comments
Ozpropdev has something already, for capturing serial info.
With the low level stuff done in HW, there should not need to be too much Logic-probe work.
At the Byte level, there are PC tools that show USB content.
First test I would to, is clip onto an idling {Host-Some-Other-Device} pair, and check it can extract the 1ms info fine, then expand that to something like simple UART 1-2 byte at a time payloads.
Do that at both FS and LS, which I guess means a mouse/kbd or similar for LS ?
I presume there is a USB mode with no internal pullups, so such a USB sniffer can connect to either FS or LS USB links.
I haven't found any LS devices other than soft implementations that are not guaranteed to be compliant. I haven't checked to see if USB Keyboards or Mouses (weird plural!) are LS or FS - guess I should do it
Chip,
What's the chances of a cut-down P2 for De-Nano or BeMicro CV ?
Guess we would need 2 cogs and a few smart pins.
What are the chances that the P2 emulation might work at 96MHz ?
It's compiling at around 78MHz now, so it would probably run fine at 96MHz.
I went to add these modes and it occurred to me that all you have to do is clear bit 6 in the PINSETM D value to disable the output enable to make a sniffer.
Meanwhile I have a P1 sniffer sort-of working at 96MHz. It's recording at 2x speed (ie 24MHz or every instruction). But because of the turn-around which can be out of sync, I lose sync although I can work out what the real situation is.
I am seeing the sync pattern followed by the short message and then EOP. This is then answered but not in original sync. I don't have enough time to resync so I am going to need to fire off more cogs, one for each message.
I haven't used series resistors to snoop. I connected D+ to P0 and D- to P1. Just using a single prop with an FT232RL and an extra USB cable that plugs into my prop. I have a cheapie USB voltage & current dongle that measures both concurrently - they have two USB out ports
It is LS, but of course it's a HID Device.
LS makes snooping easier as I can do some decoding as well.
My setup is as follows...
Laptop W10 with PropTool & PST
USB to FT232RL to Prop P30/P31 (download with PropTool, monitor with PST)..
.. USB powers my Prop board
USB to USB Voltage/Current Monitor - 2 USB out..
.. USB out to P0/P1 direct (no resistors)
.. USB out to MS USB Keyboard
LS will be very good for first testing, as it is also within spec.
FS should be ok at 80MHz, but it is nice to have one less variable in early testing.
Other SysCLK choices are 60/72/84/96MHz
84MHz will still have some small jitter, just not as often as 80MHz
I think 84Mhz has a 1/84M jitter every ~111 FS bit times.
I'm really curious to hear how much traffic there is for a keyboard or mouse.
Does every mouse and keyboard model need a unique VID/PID? I would think something so generic would have no need.
Some more useful information about keyboards/boot protocol can be found here (useful for creating drivers etc).
https://www.circuitsathome.com/mcu/programming/arduino-usb-host-part-4-peripherals
On the first SE0 I output an "e" and then wait for the end of the "J"s to start the resync again. I have just manually inserted the < and > around the sync bits to aid in reading.
FWIW I didn't expect to be able to easily sample changes of state (ie sample the transitions) even at 16x USB clock. I could also see the turnaround where the line was tri-stated for a reply. This I expected to see.
I think it might be possible to just swap the input pins D+ & D- to convert between LS and FS. The J state is the D- pin high for LS and the D+ pin high for FS.
The USB slaves can use this 1ms for DPLL use & this confirms a still-connected device.
Of course, they can have lower information data rates, with many 1ms frames empty.
Just to confirm... (let us presume the P0 & P1 pair)
P0 = D-
P1 = D+
For LS: P0 = D- = 1 = J = IDLE and P1 = D+ = 1 = K (when P0<>P1)
For FS: P0 = D- = 1 = K and P1 = D+ = 1 = J = IDLE (when P0<>P1)
LS + FS: P0 = P1 = 0 = SE0
LS + FS: P0 = P1 = 1 = SE1
Now you have to tell the smart pins whether you want LS or FS, as well as set the speed, because the smart pins need to reverse the J & K states for assembling the bits.
However, if you just swap the pins over internally (ie swap P0 with P1 ie for LS, P0 becomes J and P1 becomes K) the logic stays the same.
The LSB of the pin pair can be used to select LS/FS.
U 5V \ | USB FS S D- |------|P0 --"K"------- smart pins "K" B D+ |------|P1 --"J"------- smart pins "J" GND/ | U 5V \ | USB LS S D- |------|P0 --"J"---\/-- smart pins "K" B D+ |------|P1 --"K"---/\-- smart pins "J" GND/ | ^^ swap overFYI I use microUSB connectors for PS2, I2C, Serial, etc connections:
D+ = CLK/SCL/TXD/etc (generally an output)
D- = DATA/SDA/RXD/etc (generally an input)
I have configurable 10K pullup/pulldown & 1K5 pullup/pulldown and series 0/65R/130R in both lines.
For this reason, I have P31 (SI) on D- and P30 (SO) on D+ which is opposite to your D- on the lower pin.
I concur the pcb routing is easier with D- on the lower pin.
Polls from the space occur every 8ms. Each poll is answered 25us later (measured start of sync for poll message to start of sync for the reply). I haven't recorded the initialisation sequence yet.
I hope you toke in to account that microusb connectors is pcb bottom-mount by default,
they make top-mount connectors that is still compatible as they flip the pins.
D- needs to be P1
if you follow what everyone else does.
They follow the same layout as above.
As here is a top-mount-ab: Pin2 is D- and Pin3 is D+
http://www.molex.com/pdm_docs/sd/475900001_sd.pdf
When I last looked at this, you could not do a universal single sided USB pinout, as not all connectors have the same order.
I decided the IC's I was mumbling about at the time being backwards, are actually ok on the older full sized USB.
Even tho some call for MicroUSB as the 'new standard', I know a number of designers using largest ones for physical strength and reliability reasons. Some insist on thru hole pins.
I like at least thru hole mounting.
I have MicroUSB cables here that are just a bit flakey on the contacts, seems they went too small on this one..
I imagine lot of mice and keyboards etc would prefer to plug in using regular USB-A over micro-ab. Yes you can buy OTG adapters but that gets messy.
They make you flip the cable over, so that is why a top mount connector still works on top of a pcb board.
A usb cable has a logo on top that is not showing correctly if cable is flipped over, so bottom mount is "standard"
A smaller keyboard is something a P2 would use, comes with micro-usb plug
http://www.amazon.com/Belkin-Universal-Keyboard-Designed-Classroom/dp/B00M9DCSJ2
I sure rather have micro-ab on a develop board, as being a host or device can be changed on the fly by simply inserting the correct end of a ab-cable.
The ID-pin is shorted to ground on A side, so you check that pin and configure your software driver accordingly.
USB-A is so 1990's but if you still want to use it they make reverse-type-USB-A,
instead of you trying to mount a microusb-bottom-mount on top as that is not "standard" (but would work)
It seems that there's no best way, after all.
Does anyone besides Tonyp and I have an opinion on this? Mine's flexible, by the way, and was from looking at how a component-side Mini-B connector would best attach.
At 480MHz, length matching is somewhat more important.
Google finds numbers between 152mm/ns and 175mm/ns, so even a quite-lazy 16mm trace difference, is only 100ps, way less than the cable rise time.
But with Silabs giant Gecko ARM3, it' D- first as it has full host features.