STM32U5xx: QSPI as multi-master (release QSPI signals)

[tjaekel]

I use the OCTASPI as QSPI. So far ok (QSPI transactions work).

But I have realized:
a) the QSPI does not release any signals after a transaction has finished
b) it does not seem possible to use OCTASPI (in QSPI mode, maybe as well in single SPI mode on OCTASPI pins) in "multi-master" mode (see details below)

The OCTASPI does not release signals (at least not SCK, DIO0..3). And not possible to verify the state of NCS signal (if another master has grabbed the bus).

Regular SPI can do: see in datasheet:

So, I need QSPI (via OCTASPI) also in "multi-master" mode. It means:

a) all signals are released after QSPI has finished (SCK, DIO0..3 are floating between transactions - it does not)
b) NCS signal can be turned into an input, or use it as an Open-Drain output (with external pull-up)
c) check the status of NCS (as input or read Open Drain status) before a new QSPI transaction is launched ("not another QSPI master on the bus")

Is this possible?
Is this a missing feature?

Most "annoying": SCK, DIO0..3 are not released. Assuming NCS could be Open Drain - it does not help if those signals are not released (not floating at end of transaction).

BTW: I do not want to "de-initialize the entire QSPI again" (it works if I do). It takes too much time to re-initialize the entire QSPI (and pins) all the time again. I need a minimal overhead between two QSPI transactions (very fast "back-to-back" transactions).

Is OCTASPI (QSPI) "multi-master" capable?

[Andreas Bolsch]

No chance, I'd say. Releasing data pins and clock can be done relatively fast (just one write access to MODER register) if all these pins are on a single GPIO port (depends on package). However, this works only when OctoSPI is idle. But for multi-master you'd need some sort of locking, i.e. automatic detection of another master accessing the QSPI lines and postponing a concurrent access request. This could only be handled in software, so rather slow ...

[FBL]

Hello @tjaekel ,

I suggest implementing a software-based solution by using a GPIO pin as a software-controlled chip select signal and manually toggle it prior to each QSPI transaction or once an error is detected. This would allow you to control the bus access and avoid collisions with other masters as well.

Regarding the issue of the signals not being released after a transaction, you could try manually toggling the signals to a known state after each transaction to ensure that they are not left floating. This could be done using a GPIO pin or by reconfiguring the OCTOSPI pins to OCTOSPI mode and then back to QSPI mode.

[tjaekel]

Thank you.

All fine: I reconfigure QSPI pins and it works.

BTW: toggling nCS as GPIO before I kick off QSPI transaction can be "wrong":
If nCS comes too early (because GPIO pin set before QSPI is launched - it can generate a transaction with still floating QSPI signals, esp. SCK.

All fine.
I resolve ticket as "recolved/answered".

Best regards
Torsten