STM32U5xx: QSPI as regular SPI - not possible! - needs external tricks

[tjaekel]

Dear STM32 team,

I am a bit confused about the OCTALSPI device (using it as QuadSPI):
Why is it not possible (not supported) to use OCTALSPI also as a regular SPI?

Datasheet states that "Single-SPI" is possible - but it means actually: "Single-Lane-SPI": still in half-duplex mode (not possible to send and receive at the same time). Not regular SPI!

BTW:
It would be "cool" if the pin assignments (and ALT functions) would allow to use some QSPI signals also as regular (full-duplex) SPI signals. Why we, for instance, this mapping?

OCTALSPI1_NCS = SPI1_NS    - nice: matching
OCTALSPI1_IO3   = SPI1_MISO - bad: map it to OCTALSPI1_IO1 - mismatching
OCTALSPI1_IO2   = SPI1_MOSI - bad: map it to OCTALSPI1_IO0 - mismatrching
and the SCK signal is on different pins: mismatching

It is obvious for me, why OCTALSPI cannot work as "regular" SPI:
It is NOT possible to configure an indirect read plus an indirect write at the same time (even the DIO1 signal turns properly to an input, but it does not receive at the same time when we send).
The OCTALSPI_CR register does not allow both operations enabled (WR and RD are exclusive). So, it remains half-duplex (RD or WR, but never both).

Other issues seen on OCTALSPI (as QSPI):

• Datasheet says something like this: "you can omit any phase, e.g. no INSTR, no ADDR, no ALT, no TURN-AROUND".
  But it says also something as:
  "Any of these phases can be configured to be skipped but, in case of single-phase
  command, the only use case supported is instruction-phase-only."
  So, it means - and I can confirm:
  Just a DATA phase is not possible! You need at least a INSTR phase (one byte)
• When I do an indirect write transaction (and OCTALSPI is configured for it) - I cannot stop via breakpoint on debugger right in the loop when all the data is sent:
  If the SFRs page is open at the same time, in order to see the OCTALSPI device registers:
  the debugger dies, is disconnected and the GUI stops the debug session.
  (maybe obvious, because the _DR register is used to write but debugger polls/reads it - this seems to confuse the chip/debug).
  Not very nice behavior (making debugging difficult).

My suggestions for future versions of the STM32U5xx chip:

1. remap the pin assignment so that the QSPI pins match with a regular SPI (e.g. SPI1 uses the same OCTALSPI pins as NCS, SCK, DIO0 = MOSI, DIO1 = MISO)
2. consider if possible that during a write the OCTALSPI (in single-mode = single-lane-mode) samples also input on DIO1 (different or the same register, just to sample also the input when shifting out data)
3. make it possible to debug the chip when OCTALSPI is in write mode but debugger wants to display the _DR content (reading the same register)

===== Here the trick how to solve with external PCB routing =========

I need SPI vs. QSPI on the same pins (no need to change an external adapter, an external chip wiring...).

Options:

• have an external signal multiplexer and connect a SPI to the QSPI pins (cost effective)
• have traces (wires) connecting also a SPI, e.g. SPI1 on OCTALSPI1, pins - but use both in an exclusive way (acceptable options)
• Use the OCTALSPI as a SPI Master (it will send only), but connect another regular SPI as a slave: the OCTALSPI master provides MOSI, the SPI slave, connected on DIO1, provides the MISO.
  Just:
  Due to fact that OCTALSPI cannot generate just a DATA phase (without INSTR) - you have to send one byte as INSTR (but the SW/FW could handle that as sending the first data byte via the _IR register)

So,
to have a shared QSPI with a regular SPI without to rewire pins - works only with some external "tricks" (components or wiring).

[KDJEM.1]

Hello @tjaekel ,

For the first issue, I advise you to take a look to this How to configure Octospi as a normal Spi interface (Not interfacing with external memory devices)? and RM0456 28.4.4 OCTOSPI regular-command protocol Section.

To check the second issue "Just a DATA phase is not possible!You need at least a INSTR phase(one byte)" , which STM32U5 are you using? STM32U575 or STM32U5A9...?

Thank you,

Kaouthar

[tjaekel]

I use STM32U5A5.
Yes, all what I have mentioned was after a deep digest of the RM.

At least a INST phase needed: as cited already from RM:
"Any of these phases can be configured to be skipped but, in case of single-phase
command, the only use case supported is instruction-phase-only." (28.4.4, page 1046).

Regarding "Single-Lane-SPI" (not "regular SPI), see register 28.7.1 OCTOSPI control register (OCTOSPI_CR), page 1070:

Bits 29:28 FMODE[1:0]: Functional mode
This bitfield defines the OCTOSPI functional mode of operation.
00: Indirect-write mode
01: Indirect-read mode

So, it is not possible to do a WRITE and a READ at the same time.
We can use OCTALSPI in single-lane half-duplex SPI mode, but not in full-duplex mode (as a regular SPI would do). Single-SPI means: Single-Lane-SPI.

[tjaekel · Accepted solution]

Due to "fact" that OCTOSPI is always a half-duplex device (even in single-SPI mode, better to call it "single-lane-SPI" - it is not a "regular full-duplex SPI" - here two HW options.

Intention: the OCTOSPI (used as QuadSPI) should reuse the same pins and signals to work also as a regular (full-duplex) SPI. So, I want to have:

• IO0 = MOSI
• IO1 = MISO
• in full-duplex mode (Tx and Rx at same time)

Solution:

• use OCTOSPI as single-SPI (single-lane) Master Tx (it sends MOSI, but does not receive MISO)
• connect SCK and IO1 as MISO to another "regular" SPI (e.g. SPI1 or SPI3)
• run the "regular" SPI (SPI1 vs. SPI3) in Slave Mode - this is the Slave Rx, for MISO, using the same SCK
• SPI slave without NSS HW signal: use SW NSS mode (enable slave Rx via SW)

You lose two GPIO pins. Depending on the option - you lose entire SPI3 (option B).
With option A - the SPI1 remains available as a full regular SPI - just on different pins (with a different ALT setting).

Option A needs external components (tri-state drivers) and also some SW constraints:

• configure OTCOSPI for single-SPI mode first
• this should turn the direction of the OCTOSPI driven signals, IO3 and esp. IO1 (becoming input - works correctly)
• now you can enable the tri-state driver and "map" the IO1 (which is MISO) to IO3 (which is SPI1 MISO signal)
• Be aware of in which mode OCTOSPI is in order to avoid a pin driver conflict.

Option B is easier, does not need external active components and is free of conflicts (SPI3 is always "listener", input). You just lose SPI3 as a regular SPI device.

Run OCTOSPI as master Tx and SPI as slave Rx in parallel (e.g. in INT mode or DMA mode, at least one device).

I go with option B.

[tjaekel]

Using OCTOSPI as "regular SPI" has a caviat:

OCTOSPI is always "MSB first" - no way to configure "LSB first" (as we can do on "regular" SPI.

So, OCTOSPI (or QSPI) is "just" a "half-duplex" SPI on "single lane" (not a "regular" SPI as all other SPIx).

[KDJEM.1]

Hi @tjaekel ,

OctoSPI does not support full-duplex, only half-duplex is supported.

Note that both OctoSPI and QuadSPI work only as a master.

Thank you.

Kaouthar