STM32 MUCs: possible to route back an output signal as input - internally?

[tjaekel]

Using the STM32U5xx MCU - I see that PA4 on STM32U5A5 can be OCTOSPI1_NSS signal as well as SPI1_NSS signal.

Now, I want to use SPI1 in parallel with OCTOSPI1 (as QuadSPI). The SPI1 should be a SPI Slave Rx where OCTOSPI1 is my master QSPI Tx.

I want to know this:

• If PA4 is configured, via ALT, as OCTOSPI1_NSS (output)
• can I configure SPI1 to use HW_NSS signal (also PA4), as an input
• and the output signal on PA4 as OCTOSPI1_NSS is routed back as input to SPI1_NSS?

What I understand:

When I would configure PA4 as SPI1_NSS (via ALT) - it would become an input. OCTALSPI1_NSS would be disconnected as an output.

But what if I leave it as a OCTALSPI1_NSS but I configure SPI1 to use HW_NSS signal (but without ALT again)?
Would it be connected to the same PA4 signal, but internally, to read how OCTALSPI1_NSS is driven?

I mean: can a signal, driven as an output, still be used as an INTERNAL input (for another device)?

Actually, I guess the answer:
How would SPI1 know which pin signal to use as HW NSS? It needs also an ALT config (which disconnects the other function for this pin).

I do not know how the chip internal pinmux function is implemented. But it would be "cool" if an output signal, generated by one peripheral device could be read back as an input for another peripheral device (or to "monitor" driven outputs as GPIO inputs).

I assume: not possible (ALT is a real signal mux), just asking for my curiosity.

Sometimes I have the need to route back an output signal to another internal device as an input signal. It would be "cool" to do so, without an external wire. (knowing it is not the idea behind pinmux and ALT functions, but technically I could be possible with appropriate internal pinmux logic)

[TDK]

No, only one alternative function can be active at a given time.

[tjaekel]

Yes, I know (mentioned):

I was asking about: "if a signal is configured as output (via ALT), can another device still "see" the signal and read as an input?

Or this way: "is it possible, if a pin is configured as output, to read back this pin signal as an input (on any other means)?"

What happens if I enable a feature which needs an input (e.g. SPI as slave an NSS as input signal), but it is driven as an output, e.g. by OCTASPI_NSS?
Technically, this input signal can read back the INTERNAL pin signal without any ALT configured for this device pin.

I think, you are right: an input signal must be configured via ALT as input. "Assuming" it would read a signal, driven as output by another device - is not supported (even it could be, technically).

I think, chip designers could think about how a "pinmux" could work also in an alternative way, e.g.:
pinmux (ALT) selects the direction but a (default) input can be still using the same signal from a (default) pin (even driven as output). Or a secondary pinmux function: specify on which pin you want to "listen" as an input (even already in use as output).

Never mind: pretty obvious already it does not work (even it could work with a small change on pinmux: if a pin intended as input - without ALT: let is "listen" on default internal output signal).

[tjaekel]

I mean this:

A) the input signal is taken from the pin (directly) - OK

Why it should not be possible?

It just depends from where the pinmux selects the signal (and if it would affect the DIRection when setting an ALT):

B) the input signal is taken before the GPIO cells and ALT affects also the DIRection - FAIL

Best would be:

• If I use ALT and set as output
• but if I use ALT select as input for same pad (pin) but for other device - it should not affect the other setting: it does not change the direction of the pad (pin) - assuming (default): it is an input:
  just connect the same pad (pin) as an input, never mind who is driving this signal (from internal or from external)

If the pinmux is "just" a mapping of which signal goes to which pin (pad), but the direction is not "hard-coded", it should work, to connect an input to an existing output (internally).

If any ALT config affects also the pad (pin) DIRection: sure, it fails.
(as it looks like pinmux in chip is implemented this way)