USB Testing

167891012»

Comments

  • Rayman wrote: »
    Just one I have a work somewhere...
    Can check model tomorrow...

    Annoying thing about it is that people will come by and touch the screen not knowing it's touch sensitive and make it do some random thing...

    Got a chuckle from that last bit. I know exactly how that feels. When my kids were very young I wanted them to be comfortable with computers so I put some games and a paint program on my computer (Win 3.1) and let them play on it. Quite an educational adventure having to undo all the inadvertent changes they made.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • model is Acer T231H.
    But, I think I'm better off with mouse or keyboard anyway...
    Prop Info and Apps: http://www.rayslogic.com/
  • Since updating to latest USB code, haven't had to cycle power or reload firmware.

    But, have had to unplug and replug USB mouse a couple times to make it go..
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    But, have had to unplug and replug USB mouse a couple times to make it go..
    Low-speed or full-speed mouse?

    In my testing full-speed sometimes may need additional disconnect/connect attempts before it gets a good enumeration. Low-speed should be pretty solid.
    garryj
  • This is the cheap Amazon basic mouse. Think it's low speed.
    Prop Info and Apps: http://www.rayslogic.com/
  • I did comment out this initial delay:
    'RJA waitx   ##_1ms * 5000                   ' Startup delay to allow terminal connect
    

    Any chance that matters?

    Prop Info and Apps: http://www.rayslogic.com/
  • I don't think commenting out that delay would make a difference in your situation, as I had it there to give me time to get the PST enabled.

    I've got the Amazon Basics mouse, and it's low-speed. Is the mouse connected to the USB shield at startup? Don't really think this would matter, though. Do you have any debug output going to your terminal from the USB host? If something goes awry at connect, the host should output an error message if the initial device descriptor request fails.
    garryj
  • Yes I try to leave the mouse plugged in

    Its maybe one in 12 or so reprograms that it doesn't work until unplugged and replugged

    But maybe my messing with the code messed it up somehow
    Prop Info and Apps: http://www.rayslogic.com/
  • Version 0.9a of the USB Low/Full speed keyboard/mouse demo and "minimal footprint" source files, updated to reflect the P2 FPGA v16a changes.

    Minor improvements to device enumeration success on connect. Low-Speed devices are very solid, and Full-Speed is also solid when using USB 1.x and 2.0 devices. USB 3.0 devices are not as accommodating, and may take several connect/disconnect attempts before a clean enumeration can be achieved. My meager bus analyzing skills have so far failed to determine why that may be. Since High/Super speeds are beyond the P2's capability, I don't know how much of an issue this would be.
    garryj
  • I wonder if those 3.0 devices do some test burst at high frequency after plug-in.
  • cgracey wrote: »
    I wonder if those 3.0 devices do some test burst at high frequency after plug-in.
    I haven't really had a chance to peruse the USB 3 spec, but that was something that crossed my mind that could be a part of it. High-Speed has a J/K "Chirp" it sends during the reset state to distinguish itself from Full-Speed. If the 3.x device makes it past reset things get better, but where the 2.0 device transactions are solid, the bus signalling of the 3.x device is less stable, resulting in transaction stage failures. The retry mechanism recovers much of the time so the overall transaction succeeds, but it can get really messy.

    I've got a low-budget analyzer that only targets low/full speed, and don't have a mixed-signal o'scope, so I'm running somewhat blind when it comes to what, exactly, is happening on the wire :confused:
    garryj
  • Thanks garryj.
    I don't think any mice or keyboards or any other HIDs are USB 3.0 are they?
    If not, might not matter...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    I don't think any mice or keyboards or any other HIDs are USB 3.0 are they?
    Yeah, in the keyboard/mouse realm High-Speed is overkill. It just bugs me that the 2.0 devices enumerate cleanly, the 3.0 devices are finicky, and I don't yet see a reason why...
    garryj
  • jmgjmg Posts: 10,083
    garryj wrote: »
    Rayman wrote: »
    I don't think any mice or keyboards or any other HIDs are USB 3.0 are they?
    Yeah, in the keyboard/mouse realm High-Speed is overkill. It just bugs me that the 2.0 devices enumerate cleanly, the 3.0 devices are finicky, and I don't yet see a reason why...

    Do you have a list of parts that do not enumerate ?

    Does the FPGA USB testing use a differential pin buffer, as I think the final silicon will.
    The FPGA pin nodes are also likely to be faster than final process.

    I don't think a standard USB transceiver can connect readily to the P2 image, but you could try 22 ohm/22pF LPF to see if that makes any difference, and maybe also try the longest, 'lossiest' cables you can find.
    garryj wrote: »
    I've got a low-budget analyzer that only targets low/full speed, and don't have a mixed-signal o'scope, so I'm running somewhat blind when it comes to what, exactly, is happening on the wire :confused:
    What scope do you have ?
    Even if it cannot see the HS USB stuff, it may be able to identify when it is present, as I think that is reduced swing (similar to LVDS)
  • I thought USB 3.0 used different voltage levels... I was surprised it works even a little...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    I thought USB 3.0 used different voltage levels... I was surprised it works even a little...
    USB 3.0 is backward compatible with 2.x connect-wise. I haven't spent any time in the 3.0 spec to see what caveats, if any, may exist with down-level connection. So far I've just been testing with them because I have some...

    @jmg
    I've got a mixed bag of 3.0 thumb drives: Lexar, HP, SanDisk and Toshiba. All are finicky, some more than others. My focus has been on getting the 1.x and 2.x devices as reliable as I can, and there's much more to do there, so I haven't been too keen on burning time on what is essentially a side-trip. I'm mostly a software guy, and my skills with logic analyzers is limited (but growing), but with o'scopes (a 100MHz, 2-channel Rigol) I'm barely at the basics.
    garryj
  • jmgjmg Posts: 10,083
    edited March 2 Vote Up0Vote Down
    Rayman wrote: »
    I thought USB 3.0 used different voltage levels... I was surprised it works even a little...
    It does when running at 480M, but it is supposed to have fall-back to 12M.
    There is usually some sort of 'have a go' at differing speeds, but I would have expected a slave to follow the host, and not 'try anything fancy' until asked...

    Here is a better explanation : See Negotiating High Speed
    http://www.usbmadesimple.co.uk/ums_6.htm#negotiating_high_speed
    Looks like it does rely on correct BUS termination, in order to have the 800mV not be seen ?



    Another possible test would be to try 84MHz or 96MHz Sysclk ?

    This would remove any jitter from the BUS signals, to check/eliminate if that is having an effect ? - it may be that the USB 3.0 parts have a fussier PLL scheme, tuned for higher speeds and not tested with more ropey 12MHz signals.. ?

    I think that needs a PLL tweak in the FPGA, and depends on how much margin exists in the builds.
    84MHz is not much of a push ?

  • garryjgarryj Posts: 119
    edited March 6 Vote Up0Vote Down
    jmg wrote: »

    Another possible test would be to try 84MHz or 96MHz Sysclk ?

    This would remove any jitter from the BUS signals, to check/eliminate if that is having an effect ? - it may be that the USB 3.0 parts have a fussier PLL scheme, tuned for higher speeds and not tested with more ropey 12MHz signals.. ?

    I think that needs a PLL tweak in the FPGA, and depends on how much margin exists in the builds.
    84MHz is not much of a push ?
    I have two Sandisk "Ultra" 16GB 3.0 parts, and they enumerate very reliably. The attached analyzer screenshots show the same device descriptor request for the Sandisk part and a Toshiba 3.0 part. The Sandisk capture from index 40..58 shows a "clean" SETUP descriptor request transaction, and the Toshiba capture from index 45..65 shows a SETUP descriptor request that also succeeded, but it required three data phase IN transaction attempts to do so. In the first two attempts, the Toshiba device did not respond to the DATAx packet that follows the IN token. During an IN transaction, NOT returning an ACK/NAK/STALL handshake means the packet was missing or corrupt. Since the analyzer was able to successfully read and verify the DATAx packet, the read issue must be with the Toshiba part?

    I'd certainly like to test if it's possible to tweak the FPGA to 84 or 96MHz? Or should there be no worries if the P2 silicon is clocked at > 96MHz?
    1406 x 823 - 146K
    1406 x 823 - 143K
    garryj
  • jmgjmg Posts: 10,083
    garryj wrote: »
    ... and the Toshiba capture from index 45..65 shows a SETUP descriptor request that also succeeded, but it required three data phase IN transaction attempts to do so. In the first two attempts, the Toshiba device did not respond to the DATAx packet that follows the IN token.

    During a SETUP transaction, the device must accept the DATAx packet, and the only reason NOT to return an ACK/NAK/STALL handshake is if the DATAx packet was missing or corrupt. Since the analyzer was able to successfully read and verify the DATAx packet, the read issue must be with the Toshiba part?

    Does the Toshiba always need three tries ? (does it ever never ACK, or take dozens of tries ?)
    Maybe that is by design, and it used the NAK to 'buy time' to get things in order ?
    I understand some companies do use the retry aspect to mask their own issues.... :)
    garryj wrote: »
    I'd certainly like to test if it's possible to tweak the FPGA to 84 or 96MHz? Or should there be no worries if the P2 silicon is clocked at > 96MHz?
    I think Chip builds to 80MHz timing, which means 84MHz is probably there in margins and room temperature allowances, & 96MHz might be more of a push.

  • jmg wrote: »
    Does the Toshiba always need three tries ? (does it ever never ACK, or take dozens of tries ?)
    Maybe that is by design, and it used the NAK to 'buy time' to get things in order ?
    I understand some companies do use the retry aspect to mask their own issues....
    I haven't seen a repeatable pattern in any particular device, other than it happens most often in 3.0 parts. NAKs are common and do, indeed, signal that the device is listening, but is not yet ready to deal with data. Typically, the NAK retry ceiling is quite high, and for some functions, it can be indefinite. For genuine bus errors or corrupt packets, the spec suggests three retries before giving up on that particular transaction phase. My retry implementation is still pretty simple, so improvements there, or maybe even just upping the retry counts, could get the 3.0 parts "reliable" too -- as long as you don't look at it through the eyes of the analyzer ;)
    garryj
  • I have seen some cases where the USB 3.0 port on my laptop has had issues with USB 1 or 2 devices.
    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)
  • Was just wondering if garryj's keyboard driver could be used for games.
    It's fine for normal use, but for games more than one key can be down at same time.

    If I remember right the regular USB keyboard reports show up to 6 keys down at a time.
    So, it should be possible...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Was just wondering if garryj's keyboard driver could be used for games.
    It's fine for normal use, but for games more than one key can be down at same time.

    If I remember right the regular USB keyboard reports show up to 6 keys down at a time.
    So, it should be possible...
    Yep, 6 key rollover is part of the boot protocol. What needs to be added to the demo is to report a "key up" event for each keypress that's detected, and then it should be close to being game-ready.
    garryj
  • Any luck getting your USB code to work with V19 garryj?
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Any luck getting your USB code to work with V19 garryj?
    I made the v19 instruction changes and it assembles, but doesn't yet work. I've been diverted to other things of late, so I have yet to get the time to figure out where things went wrong. I'm hoping to get some time over the weekend to work on it.
    garryj
  • I didn't quite get to where I wanted to be over the weekend with the USB demo. I am getting complete send/receive USB transactions over the wire with P2v19 at 120Mhz, both low-speed and full-speed, but complete device enumeration is still elusive. Unfortunately, a subtle v18->v19 editing blunder had me chasing my tail for quite a while >:(. With that behind me, I'm hoping things will smooth out a bit going forward.

    @Rayman, I'll try to focus on getting at least LS mouse working in the "minimal" version ASAP.
    garryj
  • Thanks garryj!
    There's no rush though
    Prop Info and Apps: http://www.rayslogic.com/
Sign In or Register to comment.