2020-03-06 12:32 PM
Hello,
My company is evaluating a graphical application according following specs. Res. 640x360, RGB565 interface, JPEG / JPEG stream images / videos /animations. The selected uC is STM32V3A3VGT3. Data information for videos and images will be stored at flash memories. As a first approach we foresee scalability up to 256MB. For doing that, first approach is QSPI memories connected to the two OCTOSPI interfaces using Dual-QSPI configuration for each one. The idea would be to use separated Chip selects sharing 8-bit data lines or to share Chip select separating data lines. Looking for a configuration at STM32CubeMX, however, we’re only able to configure Port 1 for both OctoSPI. On the other hand, we’re not able to select separated chip select for each OctoSPI.
How should we configure it ? Is possible to configure both OctoSPI as foreseen by us ?
By the way, let’s comment that we have also evaluated using FMC for parallel memories, NOR or NAND. We notice several limitations for them. NOR memories regarding addressable memory size. NAND memories regarding performance, especially if a post-processing (Touchgfx) is later required.
Please let me know your feedback,
Thanks in advance,
Ignasi Villagrasa
2020-03-06 12:52 PM
At least some of the EVAL/DISCO boards have a dual-die Micron part, data via 8-pins (4 from each bank) and a single NCS and CLK, the data interleaves between the two, and uses a 300mil SOP16 package. The 1GBit part as I recall. See STM32H743I-EVAL(2)
If you do a JEDEC ID, each byte is read twice, even bytes from one device, odd bytes from the other, each with a different unique ID. I have working dual footprint methods working also. The 300mil package is more common across vendors, but you need to have code to support each make/model you build with.
QSPI NAND don't work as random access memory (have samples of Winbond), and don't support XIP. If you want NAND, I would suggest eMMC which supports 8-bit DDR off the SDMMC interface.
Not using CubeMX so can't help you there, but the QSPI configuration code is in the BSP drivers for the boards, with worked examples within the board trees (unpack CubeH7, or walk repository)
2020-03-06 11:17 PM
> STM32V3A3VGT3
Huh?
2020-03-07 12:19 AM
Supposing you actually mean STM32H7A3VGT: Table 1 in DS shows that 2 OctoSPI s are only available in multiplexed mode (footnote 3), i.e. both interfaces access the very same flash chips. And if you skim through Table 7 ibid., you will see that only OCTOSPIM_P1_*** are available in the 100-pin packages, whereas OCTOSPIM_P2_*** are not.
So, you can access at most two quad line flash chips *DIRECTLY*.
Hence you must find 1 GBit flash chips, maybe stacked die variants (although this complicates things considerably, as the selection of the individual die has to be handled some way). I don't see 1 GBit single die devices to be available soon.
Another approach would be to use 4 flash devices, two by two paralleled: As even in the 100-pin packages offer several possibles pins for OSCTOSPIM_P1_NCS, one could connect each pair of the 4 devices to different pins, and select between these 'banks' via switching the AF setting of the respective NCS pins. But here again this adds considerable complications like for the stacked die method.
Essentially both the stacked die and the 4 chip solution have the same software related drawbacks, so the choice should be based on (long-term) availability of the flash devices and space/layout/pricing constraints.