Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spike on ULPI D4, D7 data bus when asserting STP #159

Open
ronyrus opened this issue Jan 5, 2022 · 1 comment
Open

spike on ULPI D4, D7 data bus when asserting STP #159

ronyrus opened this issue Jan 5, 2022 · 1 comment
Assignees
Labels
needs validation described problem or solution requires further validation question question from the community that is not technical support

Comments

@ronyrus
Copy link

ronyrus commented Jan 5, 2022

This happens from time to time.
When asserting STP in the end of TX, all the data lines are supposed to be 0x00 (or 0xFF in some cases), but in steady state.
Instead, from time to time a short spike can be observed on D4 and/or D7.
The pulse is 0.8v-1.9v with the duration of ~2.5 ns

Spike on D7: (red - STP, blue - D7)
spike_on_D7

Spike on D4
spike_on_D4

Seems to be not PHY specific. I was able to reproduce it on "host" and "target" PHYs.

To reproduce I've used the 'simple_device' design from the examples.
I'm able to trigger it on D7 with a single 'get_descriptor' control transfer.
It gets the STALL response, hence the try-except in the code.

#!/usr/bin/env python3

import time
import usb1

print("sending packets ... Ctrl-C to stop")
while True:
    try:
        with usb1.USBContext() as context:
            device = context.openByVendorIDAndProductID(0x16d0, 0x0f3b)
            device.claimInterface(0)
            device.controlRead(0x80, 6, 0x0600, 0x0000, 0x000A)
    except usb1.USBErrorPipe:
        print('.', end="", flush=True)
        time.sleep(0.5)

Later on was reproduced by @zyp
spike_on_D7_by_zyp

@zyp
Copy link
Contributor

zyp commented Jan 5, 2022

IIRC when we discussed this on Discord, we came to the conclusion that it's caused by the ULPI IO not being registered but driven combinatorially.

The LUT input signals doesn't necessarily all have the same propagation delay, so when two or more inputs toggle in the same cycle, the LUT may briefly see a half-old half-new input state causing it to output the wrong value, causing glitches like this. (Picture an XOR gate with the inputs switching from 00 to 11; in either case the output should be 0, but if it briefly sees 01 or 10 in between you'll get a brief 1 on the output.)

This is not really indicative of a problem; as long as the PHY chip's setup and hold times are not violated, the glitch should be harmless.

@straithe straithe added the technical support request for technical support label Nov 9, 2022
@martinling martinling removed the technical support request for technical support label May 23, 2024
@straithe straithe added question question from the community that is not technical support needs validation described problem or solution requires further validation labels Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs validation described problem or solution requires further validation question question from the community that is not technical support
Projects
None yet
Development

No branches or pull requests

5 participants