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.
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.
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.
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.
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?
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?
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.
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.
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
I will get all my USB demos updated with the fix ASAP.
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
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 ?
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.
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.
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 ?)
Comments
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
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 ?
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
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 + 7Samuel, by "enabling pins", do you mean pins other than DP and DM?
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
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
I will get all my USB demos updated with the fix ASAP.
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 ?
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.
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%
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.
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 ?)