using Dual-Quad-SPI with OCTOSPI in STM32H5xx

[shii]

Hi,

I have been trying to connect PSRAM and NOR FLASH to STM32H563 nucleo board using Dual-Quad-SPI.

I was able to successfully read/write to PSRAM and NOR Flash individually in single-Quad-SPI mode with base address 0x90000000. i'm not clear how the addressing is taken care, when we connect both PSRAM and NOR Flash in dual-Quad-SPI mode.

[Tesla DeLorean]

Dual in ST parlance typically means two identical devices side by side

Different devices? Perhaps if you don't use the concurrently, and you can mux/swap the chip select?

[Nagarajan]

We are not going to use concurrently. Either one the of the devices will be accessed at a time. How do we mux/swap the chip select between two devices?

[Tesla DeLorean]

Should be an IOSelect or FlashID type settings. Physically would need different NCS pins.

As I've said before "Dual" means two identical devices ganged side to side.

Diagram what pins you have wired up. Certainly possible to wire things up that won't work...

[KDJEM.1]

Hello @shii and welcome to the Community :),

When DMM = 1 in OCTOSPI_CR, the OCTOSPI is in dual-memory configuration: if DMODE = 011, two external Quad-SPI devices (device A and device B) are used in order to send/receive eight bits (or 16 bits in DTR mode) every cycle, effectively doubling the throughput.

If address X is even, then the byte that the OCTOSPI gives for address X is the byte at the address X/2 of device A, and the byte that the OCTOSPI gives for address X + 1 is the byte at the address X/2 of device B. In other words, the bytes at even addresses are all stored in device A and the bytes at odd addresses are all stored in device B.

Thanks to alternate function, you can connect a PSRAM and NOR Flash memories using one OCTOSPI interface. So, you can use different GPIOs to mange the chips select and the clock.  The software should configure the chips select and the clock for the memory to be accessed.

For more information about the Dual-quad configuration, I advise you to refer to RM0481 "Dual-quad configuration" par graph under "23.4.5 OCTOSPI regular-command protocol signal interface" section and Figure 141 OCTOSPI block diagram in dual-quad configuration.

I hope this answer your request.

Thank you.

Kaouthar 

[Nagarajan]

In Dual-memory configuration, the bytes at even addresses are all stored in device A and the bytes at odd addresses are all stored in device B. We dont want to store like this as we are connecting FLASH and RAM different devices. If we use single-memory configuration and try to switch between Device A and Device B using MSEL bit, how that memory mapped mode addressing will work? for example, if Device A address is mapped with 0x90000000 means what will be the address mapping for Device B?

[KDJEM.1]

Hello @Nagarajan ,

To clarify my last comment, for dual quad mode, both devices must be identical, because in this mode the same commands and addresses are issued in parallel to both memories.

When DMM = 1, the bytes at even addresses are all stored in device A and the bytes at odd addresses are all stored in device B, as detailed in  RM0481 "Dual-quad configuration" section.

But it is possible to connect 2xQuadSPI memories using only one OCTOSPI instance.

There are 2 possible solutions:

• Use a dedicated bit in OCTOSPI_CR register for external memory selection: MSEL bit  for STM32H5: The idea is to select the external memory to be addressed in single-, dual-, quad-SPI mode in single-memory configuration (when DMM = 0).
  MSEL 
  0: External memory 1 selected (data exchanged over IO[3:0])
  1: External memory 2 selected (data exchanged over IO[7:4])
  This bit is ignored when DMM = 1 or when octal-SPI mode is selected.
  DMM: Dual-memory configuration bit in OCTOSPI_CR register. This bit activates the dual-memory configuration, where two external devices are used simultaneously to double the throughput and the capacity.
• Use different chip select GPIO pins for each memory.  The two memories must be connected to the same OCTOSPI instance, then the chip select of each memory must be connected to an OCTOSPI chip select GPIO port (for STM32H573 MCU, the OCTOSPI1_NCS must be connected to PB6 and PB10) as shown in the below figure. With STM32H573 MCU, and when transferring data to Quad-SPI memory1, it is recommended to set the Quad-SPI memory2 chip select (PB10) to high voltage by using a pull-up resistor for example.

   

Thank you.

Kaouthar

 

[LCE]

RAM + Flash in dual quad mode does not make sense at all - except when you MUX them as you seemingly already did.

Playing with fire anyway...

[Nagarajan]

@KDJEM.1 @Tesla DeLorean 

is it fine to control NCS operation like below with normal GPIO output pin?

/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_9, GPIO_PIN_RESET);
HAL_XSPI_Command(&hospi1, &cmd, HAL_MAX_DELAY);
HAL_XSPI_Receive(&hospi1, data, HAL_MAX_DELAY);
/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_9, GPIO_PIN_SET);

[LCE]

The H72x / H73x have 2 independent OCTOSPI peripherals which also support QUAD SPI.

I'm currently working with STM32H735 Discovery Kit, with a (octal SPI) HyperRam and an octal SPI Flash, both working as they should.

[Nagarajan]

Thanks for your information. I just want to know one more information like how the memory mapped mode is used. I want both flash and RAM memories should be considered as internal memory. Is it having two different addresses for memory mapping?

[ST_Doogie]

This is a fairly old topic, but I figured I'd chime in for future answer seekers as I have a similar goal as the original poster.

What didn't seem to be understood by some of the answering parties was that the OP wanted both devices to be mapped into independent "slots" in the memory map without needing to intervene with the controller in any way. They wanted the flash to reside at one base address and the PSRAM to reside at a different base address such that no reconfiguration would be needed to have their application code be able to access either simply by a memory access to the appropriate region.

I can now see that this is simply not going to be possible as there is only one logical chip select for each OCTOSPI/XSPI peripheral. Even of the second schematic method of using two pins for the chip select and "masking" one or the other by reconfiguring the GPIO as either pull-up or as the appropriate Alternate Function would require the application code or a driver to intervene and switch chip selects, which rules out being able to use DMAs efficiently if at all. Furthermore, both the flash and the PSRAM would reside at the same physical base address. Adding an external MUX doesn't help the situation although it would prevent one from accidentally enabling both devices, which could result in bus contention. It would have been nice if the split bus style's memory select control bit could also be routed to an external IO pin to control the mux but that still would not allow the mapping of each device into different base address slots.

My situation is a bit different as commented on in a different post. I'd like the PSRAM to be accessed as memory mapped and the flash to be accessed as a block device, mass storage style. I don't need to worry about base address conflicts, but I will need to ensure DMA is not accessing the PSRAM before I perform a block transfer to/from flash, and I'll also need to default the interface to memory mapped mode and PSRAM chip select "live" and reconfigure both the mode and the chip select(or memory select bit if I split the bus) any time I want to access flash storage.

The best answer from a software architecture and a performance standpoint is to use a device with two OSPI/XSPI peripherals, but I'm trying to fit this onto a small processor module board with a 100-Pin QFP as the max package size. I'll probably stick with the G4 series processor and virtualize the RAM accesses as I'm using the external storage to implement a virtual machine running a new language interpreter.

This post is too long, but hopefully will help clarify for future readers.

Cheers.