What kind of chips can I connect to QuadSPI bus

[papageno]

Hello dear experts,

Reading the ST literature abour QuadSpi, I noticed that they only mention the flash as available peripheral chips on the QuadSPI Ibus. i would like to increase the amount of RAM on the stm32F446RE to create a buffer when writing to microsd card in order to avoid some potential latency problems. Do you think it is possible to use a psram chip (APS1604M-3SQ QSPI PSRAM ) from apmemory on the Qspi bus ?

Thank you for your help and advices.

pap

[Tesla DeLorean]

>>Do you think it is possible to use a QSPI PSRAM chip..

No, not in a memory mapped mode. You might be able to send commands/data streams to it, although I'm not sure that would be more efficient than writing to the SD card directly.

Some of the new H7 support mapped read/write

What's compelling about the F446 that couldn't be better solved with something newer, that has more internal SRAM?

[Alex - APMemory]

Just to complete the reply, the NOR Quad Memory controller support all function except Memory Mapped Write Operation.

As mentionned, the latest MCU (H7, L4+/L5...) are supporting QSPI SDR/DDR and OPI DDR RAM

Alex

[papageno]

Thank you Clive,

Sharp advices as usual.

I guess the stm32F423 with 320KB of RAM should be ok, and apparently not to far from the 446. Our second step involves two stm32 communicating, the V3 will use more recent and more powerful procs, maybe one including one M7 and one M4... Just have to jump the gun. :)

regards,

pap

[Tesla DeLorean]

For data storage might want to look at the QuadSPI NAND devices, Winbond has a 1Gbit part, haven't benchmarked write speeds. However these might have higher RAM burdens if trying to modify data mid-block, file system choice would be important here, so journalling rather than trying to crowbar FatFs implementation.

eMMC devices can use SDMMC interface in 4 or 8-bit modes. Performance would be more consistent than random speed/size cards an end user might furnish.

[Alex - APMemory]

Some customers could use QSPI RAM (better to use APS1604M-3SQR rather than APS1604M-SQ) with stm32F.... However ST support the QSPI memory controller for NOR. It is not recommended for RAM support because of one specific limitation it doesn't support Memory Mapped Write. Some customers who need low pin count external RAM and can manage this limitation are still using QSPI RAM on their own choice.

For an efficient use of IoT RAM (QSPI SDR, QSPI DDR, OPI) latest STM32 (for example L4P5, L5, H7A/B, H72x/3x, ...) version can support OPI or QSPI.

Here would be some IoT RAM suggestions:

  - OPI is available from 64Mb to 512Mb in BGA24 or WLCSP (APS6408L, APS12808…, APS25608N…, APS51208N…)

 - QSPI DDR 128Mb WLCSP (APS12804O-DQ-WA)

 - QSPI SDR from 16Mb to 128Mb, SOP8/USON8/WLCSP (APS1604M-…, APS6404L-…, APS12804O-…).

[Harvey White]

I have precisely the same question, but have already seen that the F4 QSPI does not support memory write in memory mapped mode. I have a graphics application (that like all graphics applications) eats memory.

The F7 series (F767) has a QSPI memory controller, I have boards designed to use the WinBond chip, so the footprints match.

The F7 series (says that it supports write in memory mapped mode, the one I need), but the CubeMX configuration shows no sensitivity (or controls) for a mode that I see in the L5 series.

I'm getting the feeling that the APS1604M-3SQR (which I have) might be able to be read properly, but can't be written in memory mapped mode, only a command mode (which does not help all that much. I have software that I could use to fake a partitioned memory (with somewhat of a FAT table), but that's not what I want.

Currently, I'm using a design with the L5 chips because that's the only chip in stock that has halfway decent RAM and FLASH.

So have I gotten this right? I can easily put a chip in to the QSPI interface on the F767, but I have the feeling it won't work at all the way I want. (memory mapped read and write).

[Alex - APMemory]

Based on my understanding, none of the STM32 QSPI NOR memory controller are supporting Memory Mapped Write (so no F7 series is supporting QSPI RAM Memory Mapped Write).

The L4P5, L5, U5, H72x/3x, H7A/B series does support OPI/QSPI DDR/QSPI SDR

So back to your question, you got it right, you could run QSPI RAM (APS1604M..., APS6404L,... APS12804O...) on F767, but without Memory Mapped Write mode.

Regards

Alex

[Harvey White]

Thanks, that answers the question. I need to shift from the F7 series to something else, specifically the chips you mention that support QSPI write on the OCTOSPI interface. SDRAM on a daughterboard hooked to a nucleo 144 (F767) is not stable.

[Alex - APMemory]

Hi Harvey,

Let me add one more comment to help your choice. STM32H7A/B & STM32H72x/3x are full spec with OPI (11 pin) & QSPI DDR (7 pin), but also have a limitation on QSPI SDR (6 pin) for memory mapped wirite. If you really focus only on the QSPI SDR RAM, STM32L4P5, U5, or coming low power or high performance MCU are covering all IoT RAM option (OPI, QSPI DDR & SDR, from 16Mb up to 512Mb, all available at Mouser for prototyping).

Alex

[Harvey White]

I did a cursory check through Mouser, and it looks like the STM32H7A3ZIT6 would fill the bill. What I need is a lot of memory (I do graphics and most everything is packet driven), I need the TQFP-144 package for the pinouts, and TQFP for a package I can actually solder. While SDRAM is available with the FMC interface, the board layout is nasty, even with a 4 layer board (trying to equalize track length). I've got 22 or 33 ohm resistors in series to minimize ringing, a ground plane, and three signal layers (with ground pours).

I'll be using the QSPI interface, which while slower, can be better behaved (I hope). I'm also using an Epson S1D13517 chip. Uses external SDRAM (already have that working and drivers for it). But since you can't read from the chip, more memory is useful for read/modify/write operations.

Already have drivers to handle memory mapped extended memory (and works with FreeRTOS).

Any suggestions? And thanks for your help, nice to get another viewpoint.

[Alex - APMemory]

With the STM32H7, my RAM suggestion would be to investigate OPI APS6406L, APS12808L, APS25608N, APS51208N in BGA24, 11 signal pin. This will be same performance as SDRAM / FMC but with uncomparable less pin count and power...

https://www.mouser.de/c/semiconductors/memory-ics/dram/?q=apmemory&package%20%2F%20case=BGA-24

Alex

[Harvey White]

BGA chips are a non-starter. I assemble my own boards and can't handle BGA (and don't really want to). I could design them, but doing it? I don't care to. Getting the board house to put parts on would be, I think, a bit more expensive than I want especially on a first design iteration. If I can find any of these in a more amenable package, I'll give it a try. (Don't think that the option exists, though).

May have to stick with the SO-8 package and take a performance hit.

Thanks

[Harvey White]

Looks as if nobody makes OctoSPI memory in anything but BGA packages, according to Mouser.

Oh, well...........

Thanks

[Alex - APMemory]

You are right, Octo SPI is only BGA or WLCSP.

I agree QSPI SOP8 IoT RAM is a very simple and an easy to use solution (https://www.mouser.de/c/?q=QSPI%20SOP8). However for QSPI SDR & high performance STM32, you need to wait next MCU. In short term, if you could use Low Power Series (L4P5, L5, U5), then QSPI SOP8 already works full spec.

Alex