USB Testing

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???
My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
«13456714

Comments

  • 406 Comments sorted by Date Added Votes
  • Cluso99 wrote: »
    1. Some form of data logging (logic analyser style)
    How to achieve this ???

    Ozpropdev has something already, for capturing serial info.

    Cluso99 wrote: »
    Any other ideas??? Or comments on the above???

    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.

  • Good idea about the sniffer mode with no resistors.
  • Cluso99Cluso99 Posts: 12,963
    edited March 2016 Vote Up0Vote Down
    I have actually sniffed the USB a few years ago. It is easy to setup - just a couple of 1K series resistors (for safety) into Prop pins P0 & P1 works fine. No pullups or pulldowns. I used a passive USB Hub to parallel the USB device and sniffer. Then just a USB cable terminated in pin sockets with/without series resistors.

    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • On a DE0-Nano you can get one cog and 8 smart pins. I'll definitely make that when we get this next round of changes done.
  • Thanks Chip.
    What are the chances that the P2 emulation might work at 96MHz ?
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Thanks Chip.
    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.
  • cgracey wrote: »
    Good idea about the sniffer mode with no resistors.

    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.
  • cgracey wrote: »
    cgracey wrote: »
    Good idea about the sniffer mode with no resistors.

    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.
    Excellent.

    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 :)

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • FWIW Just changed my setup to snoop on a MS USB Keyboard.
    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
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »

    LS makes snooping easier as I can do some decoding as well.

    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.
  • Cluso99 wrote: »
    FWIW Just changed my setup to snoop on a MS USB Keyboard.
    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

    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.
  • cgracey wrote: »
    I'm really curious to hear how much traffic there is for a keyboard or mouse.]/quote]
    I will do some traffic timing a little later. Currently I am increasing the pasm handling to mimimise what I put into the hub buffer for display.
    Does every mouse and keyboard model need a unique VID/PID? I would think something so generic would have no need.
    I presume the answer is the same as for other USB devices like the FT232RL. The same VID/PID is used, plus a unique serial number. There is also a description.

    If the VID/PID is the same for 2+ devices plugged in, then the same driver is used for both devices. So if you have a different implementation that requires a different driver then the VID/PID must be different.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Mice and keyboards are polled by the host and on a LS bus I think that is likely to be at most 1000 times a second. They nominate their minimum polling rate in the endpoint descriptor they publish in terms of 1ms frame intervals. If it says 10 for this then in wants to be polled at 100Hz. Depending on if they have data to report and if they are in the boot protocol mode or using some other custome features etc they can respond with say about 4 bytes (mouse) or 8 bytes (kbd) of data in the reply per call. So it is fairly low bitrate but ongoing traffic on the bus (unless it suspends).

    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
  • Here is a short dump of the MS USB Keyboard traffic. I haven't captured from reset. Traffic starts after a previous EOP (SE0+SE0+J) and ignores the following IDLE "J"s. So the start is KJKJKJKK which is the SYNC.
    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.
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJKe
    <KJKJKJKK>KJKKJJJKKKJKJKJJKJKJKKKKe
    <KJKJKJKK>JJKKKJJ
    

    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • rogloh wrote: »
    Mice and keyboards are polled by the host and on a LS bus I think that is likely to be at most 1000 times a second. They nominate their minimum polling rate in the endpoint descriptor they publish in terms of 1ms frame intervals. If it says 10 for this then in wants to be polled at 100Hz.
    Yes, I think the USB always has a poll every 1ms, (+/- 500ns, but most are far less jitter than that)
    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.
  • Yes, swapping the pins makes the difference. The USB mode takes care of all that. Also, I made the upper pin (odd) the DP and the lower pin (even) the DM, since they can be routed straight from the package to the USB connector.
  • Cluso99Cluso99 Posts: 12,963
    edited March 2016 Vote Up0Vote Down
    cgracey wrote: »
    Yes, swapping the pins makes the difference. The USB mode takes care of all that. Also, I made the upper pin (odd) the DP and the lower pin (even) the DM, since they can be routed straight from the package to the USB connector.
    Chip,
    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 over
    

    FYI 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Just tested the timing for LS with MS Keyboard...
    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • tonyp12tonyp12 Posts: 1,864
    edited March 2016 Vote Up0Vote Down
    I made the upper pin (odd) the DP and the lower pin (even) the DM, since they can be routed straight from the package to the USB connector.

    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.
    hirose_zx1.jpg?la=en&ts=a513e9e5-9710-41d6-a28c-ea579983399e>
  • D+ needs to be P0
    D- needs to be P1
    if you follow what everyone else does.
    364 x 256 - 8K
  • So what about host side ports, ie. the USB-A connectors? I think they go 5V, D-, D+, GND right? In an anticlockwise order around the chip that would work well for Chip's pin order allocation without needing crossovers.
  • If P2 is a host I would think you would use a micro-ab (USB on the go)
    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
  • tonyp12 wrote: »
    they make top-mount connectors that is still compatible as they flip the pins.
    How do you mean flip the pins ?

    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..


  • @tonyp12
    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.
  • tonyp12tonyp12 Posts: 1,864
    edited March 2016 Vote Up0Vote Down
    >How do you mean flip the pins ?

    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_micro_a-b_high_speed_cables_minilink.jpg

    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)
  • tonyp12 wrote: »
    D+ needs to be P0
    D- needs to be P1
    if you follow what everyone else does.

    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.
  • Swapping two wires should not be of any relevance, as every layout has so many signals and vias, ... So, don't wast time solving a non existing problem
  • tonyp12 wrote: »
    >How do you mean flip the pins ?

    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"
    but the image you posted above of 3 connectors, does not do that cable-flip ?

  • ErNa wrote: »
    Swapping two wires should not be of any relevance, as every layout has so many signals and vias, ... So, don't wast time solving a non existing problem
    Agreed, certainly at 12MHz, it is of no practical significance.
    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.

  • It looks like if MCU is mostly a usb device with usb-on-the-go feature, it is D+ first as in Cypress P5
    But with Silabs giant Gecko ARM3, it' D- first as it has full host features.
    502 x 89 - 8K
    574 x 75 - 3K
Sign In or Register to comment.