USB Testing

1141516171820»

Comments

  • samuellsamuell Posts: 406
    edited 2019-05-16 - 21:13:05
    VonSzarvas wrote: »
    samuell wrote: »

    However, as in the MSC driver, only the upper port works on the add-on board.

    Kind regards, Samuel Lourenço

    Hi Samuel,

    Just to double check that both power enable pins are getting set; the upper and lower usb sockets each have an ENable pin.
    basepin+1 and basepin+5

    garryj's post/code above includes those, but maybe some older code didn't assert both?
    These pins act as they are very high impedance. As soon as I try to measure the voltage on pin 1 with the device connected to the upmost port, the device disconnects. I'm essentially disabling the power switch on the board because the burden resistance of the DVM is enough to "ground" the pin. I've noticed that, although having no effect on terminal, I can disable the lower port by trying to measure between pin 5 and ground. I've concluded that by observing the LED on the pen.

    The measured voltages are always on the order of tens of mV. I get the same voltages if I try to measure between any of these pins and VIO_3V3. I was expecting pin 1 and 5 to be output pins. but they seem to be close to floating.

    Kind regards, Samuel Lourenço
  • Is there some problem with the DP/DM pin driving in the USB smart pin mode?
  • I don't think the USB smart pin mode is involved, as I'm using the P2-Eval board + the Serial Host accessory board and both ports are working nicely.
    garryj
  • jmgjmg Posts: 13,932
    cgracey wrote: »
    Is there some problem with the DP/DM pin driving in the USB smart pin mode?
    I think (hopefully?) it's more a labeling/config issue as one reports ok and another reports no activity ?
    garryj wrote: »
    I'm at a loss as to why the lower port is not working, as that is the one I usually test with:
    Can you confirm which Specific P2 pins (pin pairs) you have tested USB on ?
    In theory, it should work on any valid pin-pair, right ?


  • jmg wrote: »
    garryj wrote: »
    I'm at a loss as to why the lower port is not working, as that is the one I usually test with:
    Can you confirm which Specific P2 pins (pin pairs) you have tested USB on ?
    In theory, it should work on any valid pin-pair, right ?
    I normally work with the Serial Host board on the pin group starting at pin #16. Moved it to group #24 and all is good there, too. D- must be connected to an even pin# for the smart pins to do their thing.
    garryj
  • This sounds like an issue with providing the 5V power that devices need..
    Prop Info and Apps: http://www.rayslogic.com/
  • samuellsamuell Posts: 406
    edited 2019-05-17 - 01:06:54
    Rayman wrote: »
    This sounds like an issue with providing the 5V power that devices need..
    I've confirmed that it is not the case. The lower port provides power as well. However, the enabling pins should not be floating. Even touching with a finger will ground those pins and disable power going to the devices.

    But, I'm certain that this is not the only problem, since the lower port is powered as well. There must be another factor. I can "blink" pins 25 (1 on add-on board) and 29 (5 on add-on board) via TAQOZ and the power on each port "blinks" accordingly.

    Kind regards, Samuel Lourenço
  • I've been testing USB keyboards on both top and bottom sockets on different pin groups too.
    Works fine here.
    For refrence here's the pin offsets I use.
    Eval accessory board top socket
    
    	usb_enable = usb_basepin + 1
            DM = usb_basepin + 2 
            DP = usb_basepin + 3 
    
    Eval accessory board bottom socket
    
    	usb_enable = usb_basepin + 5
            DM = usb_basepin + 6 
            DP = usb_basepin + 7 
    
    Melbourne, Australia
  • cgraceycgracey Posts: 11,711
    edited 2019-05-17 - 05:08:39
    samuell wrote: »
    Rayman wrote: »
    This sounds like an issue with providing the 5V power that devices need..
    I've confirmed that it is not the case. The lower port provides power as well. However, the enabling pins should not be floating. Even touching with a finger will ground those pins and disable power going to the devices.

    But, I'm certain that this is not the only problem, since the lower port is powered as well. There must be another factor. I can "blink" pins 25 (1 on add-on board) and 29 (5 on add-on board) via TAQOZ and the power on each port "blinks" accordingly.

    Kind regards, Samuel Lourenço

    Samuel, by "enabling pins", do you mean pins other than DP and DM?
  • samuell wrote: »
    Rayman wrote: »
    This sounds like an issue with providing the 5V power that devices need..
    I've confirmed that it is not the case. The lower port provides power as well. However, the enabling pins should not be floating. Even touching with a finger will ground those pins and disable power going to the devices.

    But, I'm certain that this is not the only problem, since the lower port is powered as well. There must be another factor. I can "blink" pins 25 (1 on add-on board) and 29 (5 on add-on board) via TAQOZ and the power on each port "blinks" accordingly.

    Kind regards, Samuel Lourenço


    Correct. ENable is a high impedance input that controls the 5V power out.

    That ENable pin should be set LOW in your code (or enable smartpin pulldown) during code startup.

    When you want either USB port to output 5V, then set the appropriate EN pin HIGH (basepin+1 for the upper USB, basepin+5 for the lower USB).

    D+ and D- are not controlled by the switch. They are always connected from the socket to the basepin+X. Although granted, you'd likely want 5V-out active in most applications!

    Part number for the switch is: TPD3S014-Q1


    Given that you are measuring 5V at the lower port, it would seem the issue is elsewhere....

    Is there a short between D+ and D- perhaps?
    OR a path to ground?
    Have you tried the accessory module in another header position?
  • samuellsamuell Posts: 406
    edited 2019-05-17 - 13:33:57
    cgracey wrote: »
    samuell wrote: »
    Rayman wrote: »
    This sounds like an issue with providing the 5V power that devices need..
    I've confirmed that it is not the case. The lower port provides power as well. However, the enabling pins should not be floating. Even touching with a finger will ground those pins and disable power going to the devices.

    But, I'm certain that this is not the only problem, since the lower port is powered as well. There must be another factor. I can "blink" pins 25 (1 on add-on board) and 29 (5 on add-on board) via TAQOZ and the power on each port "blinks" accordingly.

    Kind regards, Samuel Lourenço

    Samuel, by "enabling pins", do you mean pins other than DP and DM?
    Hi Chip. I'm referring to the USB enable pins, offset 1 and 5.
    VonSzarvas wrote: »
    samuell wrote: »
    Rayman wrote: »
    This sounds like an issue with providing the 5V power that devices need..
    I've confirmed that it is not the case. The lower port provides power as well. However, the enabling pins should not be floating. Even touching with a finger will ground those pins and disable power going to the devices.

    But, I'm certain that this is not the only problem, since the lower port is powered as well. There must be another factor. I can "blink" pins 25 (1 on add-on board) and 29 (5 on add-on board) via TAQOZ and the power on each port "blinks" accordingly.

    Kind regards, Samuel Lourenço


    Correct. ENable is a high impedance input that controls the 5V power out.

    That ENable pin should be set LOW in your code (or enable smartpin pulldown) during code startup.

    When you want either USB port to output 5V, then set the appropriate EN pin HIGH (basepin+1 for the upper USB, basepin+5 for the lower USB).

    D+ and D- are not controlled by the switch. They are always connected from the socket to the basepin+X. Although granted, you'd likely want 5V-out active in most applications!

    Part number for the switch is: TPD3S014-Q1


    Given that you are measuring 5V at the lower port, it would seem the issue is elsewhere....

    Is there a short between D+ and D- perhaps?
    OR a path to ground?
    Have you tried the accessory module in another header position?
    I could try other header position. But since the code is not mine, I'm having difficulty finding the variable where the offset can be changed.

    Update:
    Tested pins 24 to 31 as blinking outputs, with TAQOZ, and found no issues. Also tested the add-on board separately for shorts to ground or IO_3V3, and detected no problems whatsoever.

    Kind regards, Samuel Lourenço
  • Regarding the USB issue of full-speed "frame jitter" when using a sysclock of 148.5MHz from this post:
    https://forums.parallax.com/discussion/comment/1478436/#Comment_1478436.

    The ISR routine that transmits the full-speed 1ms frame and low-speed 1ms "keep alive" signal had a rounding error that affected the 500KHz part of the sysclock, which pushed the frame timing out of spec :grimace:
    I will get all my USB demos updated with the fix ASAP.
    garryj
  • jmgjmg Posts: 13,932
    garryj wrote: »
    Regarding the USB issue of full-speed "frame jitter" when using a sysclock of 148.5MHz from this post:
    https://forums.parallax.com/discussion/comment/1478436/#Comment_1478436.

    The ISR routine that transmits the full-speed 1ms frame and low-speed 1ms "keep alive" signal had a rounding error that affected the 500KHz part of the sysclock, which pushed the frame timing out of spec :grimace:
    I will get all my USB demos updated with the fix ASAP.
    That means you fixed the analyser error messages ? Cool.

    I think means USB is more generally 'Any Sysclk' tolerant ?
    What is the lowest SysCLK speed P2 can use, to still be able to support FS-USB ?

  • jmg wrote: »
    That means you fixed the analyser error messages ? Cool.

    I think means USB is more generally 'Any Sysclk' tolerant ?
    What is the lowest SysCLK speed P2 can use, to still be able to support FS-USB ?
    Yep, the analyzer is happy again. After P2 v1 silicon came out, I removed the "shortcut" code that enabled full-speed to run on the 80MHz FPGA, so 96MHz is currently the "official" floor sysclock.
    I haven't done much testing regarding sysclocks beyond the frequencies I've seen in use on the forum. I just bumped the sysclock from 148.5MHz to 148.75MHz and the analyzer stays happy.
    garryj
  • jmgjmg Posts: 13,932
    garryj wrote: »
    Yep, the analyzer is happy again. After P2 v1 silicon came out, I removed the "shortcut" code that enabled full-speed to run on the 80MHz FPGA, so 96MHz is currently the "official" floor sysclock.
    I haven't done much testing regarding sysclocks beyond the frequencies I've seen in use on the forum. I just bumped the sysclock from 148.5MHz to 148.75MHz and the analyzer stays happy.
    What is the new jitter on the 1ms ?
    Many clock-less USB-UARTS use the 1ms info to lock/re-calibrate their RC oscillators and the MCUs I've looked at, usually have steps of ~0.5% or less in their trims.
    IIRC the 500ns error report threshold, that would be 0.05% and 100ns would be 0.01%
  • The only information in the analyzer docs regarding the "jitter" it was reporting just pointed to this USB 2.0 spec section:

    7.1.12 Frame Interval
    The USB defines a frame interval (TFRAME) to be 1.000 ms ±500 ns long. The USB defines a microframe
    interval (THSFRAM) to be 125.0 μs ±62.5 ns long. The (micro)frame interval is measured from any point in an
    SOF token in one (micro)frame to the same point in the SOF token of the next (micro)frame.

    Since the Host Controller and hubs must meet clock accuracy specification of ±0.05%, they will automatically
    meet the frame interval requirements without the need for adjustment.
    The frame interval repeatability, TRFI (difference in frame interval between two successive frames), must be less
    than 0.5 full-speed bit times.
    The microframe interval repeatability, THSRFI (difference in the microframe
    interval between two successive microframes, measured at the host), must be less than 4 high-speed bit times.
    Each hub may introduce at most 4 additional high-speed bits of microframe jitter.
    Hubs and certain full-/high-speed functions need to track the (micro)frame interval. They also are required to
    have sufficient frame timing adjustment to compensate for their own frequency inaccuracy.

    I think, in the case of my coding faux pas, the "jitter" the analyzer was reporting was that the TRFI was out of range (in bold above). This makes sense, since the USB NCO was configured using the correct sysclock (148.5MHz), but the frame interval calculation error skewed the timing.
    garryj
  • jmgjmg Posts: 13,932
    garryj wrote: »
    ...

    The USB defines a frame interval (TFRAME) to be 1.000 ms ±500 ns long.
    ...
    The frame interval repeatability, TRFI (difference in frame interval between two successive frames), must be less
    than 0.5 full-speed bit times.

    The sub ±500ns absolute stability is likely fine for any MCU-locking, (±0.05% is well under their trim steps) but the second part suggests a finer jitter/variation number of 0.5/12M = 41.667ns
    Are you now able to position TFRAME with less than 41.667ns of jitter between two successive frames ? (that's 4 sysclks at 96MHz)
    (does your analyzer catch that fine jitter ?)
Sign In or Register to comment.