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

Peripheral signal API does not force signals to be routed through the GPIO matrix #2273

Open
bugadani opened this issue Oct 3, 2024 · 3 comments
Labels
bug Something isn't working status:needs-attention This should be prioritized

Comments

@bugadani
Copy link
Contributor

bugadani commented Oct 3, 2024

This could result in some funny behaviour if the user expect to loop back a GPIO into a peripheral, but the signal is not going through the GPIO matrix.

(For example, bitbanging SPI clock for slave loopback may not be output if the loopback pin is FSPICLK)

@bugadani bugadani added bug Something isn't working status:needs-attention This should be prioritized labels Oct 3, 2024
@Dominaezzz
Copy link
Collaborator

If I remember correctly you don't need the GPIO matrix for loopback/interconnect.

It should be fine for the output to go via io_mux and input to go via matrix, so long as the GPIO pad has both input and output enabled. (Which you have to do in the right order based on the current GPIO code)

@bugadani
Copy link
Contributor Author

bugadani commented Oct 3, 2024

You kinda do (need the matrix), because you can't select two alternate functions for the same pin. I spent more time on this today than I'd like to admit.

@Dominaezzz
Copy link
Collaborator

Oh, I'd always thought of it as selecting an alternative function for the pin and an alternative function for the input signal, TIL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working status:needs-attention This should be prioritized
Projects
Status: Todo
Development

No branches or pull requests

2 participants