Unable to connect multiple HyperRAM modules to a single OCTOSPI interface

[ManuelAlcazar]

Hi all! This is my first post in the community.

Me and my colleagues are designing a System on Module powered by the STM32H735IG MCU.

We are trying to discover how to connect multiple HyperRAM modules to a single OCTOSPI interface in Memory Mapped mode.

For doing this, we need to use several Chip Select (CS) pins in order to specify the HyperRAM chip. However, the OCTOSPI interface seems to only provide a single CS pin.

Is possible to configure the OCTOSPI interface to use more than one chip select?

If not possible, how can we connect several HyperRAM modules to the STM32H735?

Thanks in advance. Regards,

Manuel

[Uwe Bonnes]

At least the high speed modes are meant as point-to-point connection. Using it as a bus will introduce stubs and so reflections . On most STM32 with these high speed connections, you have multiple instancee to connect RAM and flash.

[Uwe Bonnes]

Have also a look at AN5050

[KDJEM.1]

Hello @ManuelAlcazar and welcome to the Community 🙂,

As mentioned by @Uwe Bonnes , I recommend you to take a look at AN5050 and precisely  "Octo-SPI mode when two external octal memories are connected" section.

This section explain how to connect two memories to an Octo-SPI interface. 

In this example, the the two memories must be connected to the same instance, then the CS pin of each memory must be connected to an OCTOSPI_NCS GPIO port as demonstrated in the figure below:

For that you need to refer to STM32H735 datasheet to choose the CS pins.

Thank you.

Kaouthar

[ManuelAlcazar · Accepted solution]

Hello again,

Firstly, thank you very much @Uwe Bonnes and @KDJEM.1 for both responses. I have read several times the AN5050 application note document, as you indicated.

In the mentioned document, they say that the proposed connection is possible though the OsctoSPI (GP)IO Manager. However, I didn't found neither in the documentation nor in the HAL drivers how these pins can be configured without using the multiplexed mode (which uses both OSPIs instead of one).

Secondly, meanwhile, I was chatting with @Radek RIPA (ST employee) and he answered me in the customer support. I think his messages are super helpful, so I'll post here for all the community. Hope it helps 🙂

For OctoSPI in Multiplexed mode:

@Radek RIPAwrote:

---

The OSPI periphery is designed only to handle one memory at time.
There is one solution to use OSPI1 and OSPI2 in multiplexed mode. That the both peripheries will use same clock and data pins but the CS will be separated for each memory.

There is no other solution for memory mapped mode. Possibility would be to have switch that can be controlled to redirect the CS to one or second memory. But switch must be managed manually and the SW must take care of memory consistency. which is not expect as efficient solution.
...
If you have MX simply select xSPI1 in multiplexed mode and xSPI2 in multiplexed mode and you will see.
they will share D0...Dx, CLK, DQS. And have separated CS.

---

For OctoSPI without Multiplexed mode:
@Radek RIPAwrote:

---

...
The solution is different.

They use one SPI interface for example OSPI1
The trick is that the OSPI1 must have CS alternate function possible on two pins. For example on H735 OSPIM_P1_NCS is on PE11, PB10, PG6, PC11, PB6.
You select two of them for example PE11 and PB10. And connect the two memories there.
If you want use memory1 you configure PE11 as alternate function for OSPI. And PB10 must be as output high.
When you want use memory2 the PE11 will be high and PB10 will be as alternate function.

This change must be done by code is not automatic like in multiplexed mode.

---

Thank you all for the replies. Best regards,
Manuel

[Tesla DeLorean]

Opaque customer support doesn't help the forum..

Doesn't the BGA allow for OCTOSPI1 and OCTOSPI2 are two distinct memory regions? 0x90000000 and 0x70000000

That should facilitate the use of caching, which manually muxing GPIO pins to NCS functionality just isn't going to support effectively.

I'd hope OCTOSPI1/2 can hold two different concurrent memory-mapping templates.

I don't hold out a lot of hope that this has all been well thought out and validated. I suspect it's going to take a couple of STM32 design iterations before HyperRAM is going to work as effectively as 256MB of SDRAM

If you've got high RAM utilization you'd perhaps want to be using different architectures..