How to configure Octospi as a normal Spi interface (Not interfacing with external memory devices)?

[MFolk.1]

I am programing the STM32L4S9AII6 using the STM32L4R9I-EVAL board. My application requires the use of 5 different SPI buses, but the STM32L4S9AII6 only has 3 standard SPIs. However, it has 2 Octospi buses that I understand can be configured to be standard SPIs. Is this true or have I been mislead? Can someone shed some light on how to configure an Octospi as a standard full-duplex spi? Preferably using MxCube.

 

More specifically, I want it to be equivalent to this standard SPI configuration:

[Pavel A.]

>My application requires the use of 5 different SPI buses

What if you put two or more devices on one SPI with different chip selects?

[Andreas Bolsch]

Full-duplex means transmit and receive simultaneously or: data exchange between master and slave.

That is *NOT* possible with OctoSPI (nor QuadSPI). These interfaces a specifially designed for merory accesses, where you've either a read or a write, never both simultaneously.

[MFolk.1]

Okay, so lets say for some cases I don't care to read & write simultaneously. Is it possible to get it to behave like normal spi otherwise?

[MFolk.1]

I'm already doing a lot of that. The reason is because I have very strict timing requirements. I might be able to combine more of them, but would much prefer to use the 2 octospi buses if that is possible.

[MFolk.1]

Also, not all of the spi busses are configured with the same specs.

[MFolk.1]

From the reference manual:

 

So can Octospi transmit/receive simultaneously or not?

[Tesla DeLorean]

>>So can Octospi transmit/receive simultaneously or not?

You have hardware in front of you, you could test that for yourself surely?

My read of the documentation, diagrams, and supporting software is there isn't a TransmitReceive model here, the data phases are either Read OR Write, not both at once, the FIFO/DR plumbing similarly doesn't seem to accommodate that.

The Single-SPI SO/SI function is one of mapping pins/signals, these are the defined source/sink points, but no wording supporting that they operate concurrently. It's not going to fight data on the SI pin, and you could likely inspect the GPIO, or connect it elsewhere to capture.

[MFolk.1]

I agree with you Tesla. I am at the lab bench to test this for myself, but I'm not making it far as the Octospi HAL API library supplies no such transmit & receive api call.

[MFolk.1]

Tesla,

Can you point me to some sort of documentation that states that Octospi Cannot transmit and receive at the same time? I am having a hard time defending this to my team.

[Andreas Bolsch]

Just read RM0432, section 19.4.3. Instruction, address, alternate are "send to slave only", dummy is nothing at all, data is either "send to slave only" or "read from slave only" (depending on memory-mapped/indirect write or read).

The diagrams below are just for brevity, instead of showing two separate diagrams for both directions, they're combined into one. That's well-known and well-established convention, see e.g. datasheet of MC6821, Fig. 1 Bus timing as of 1985(!!!).

[MFolk.1]

[duke29]

im not sure but that and  you can try the following plan to imeplement  the full duplex  mllti  spi which transport byte revelop to the bit at each channel .

 the menu dm00407776 show that  the  octoSPI 1/2 in common clock source hence user can use octoSPI 1 as “muli  MISO  ”and octoSPI2 “as muli  MOSI ”  vice versa   ，octoSPI1/2  driven by same time sequence  to fulfil full duplex SPI

that is feasible or ont depend on the specific characteristic of  target chip