Hello, I try to figure out if and how it is possible to use dual qspi with two separate flashes, one for the application (program) and one for the file system (data).

[T J]

You would have to write your own handler or maybe some circuitry.

You could use a LS138 to share the nSS pin around 8 flash devices, without adjusting the QSPI firmware functionality.

[Andreas Bolsch]

Apart from using an external decoder like LS138, most STM32 devices with QSPI have dual flash capability and accordingly two separate NCS signals. So even without an external decoder two flash chips can be used, either simultaneously (by setting DQM bit) or alternatingly (when DQM cleared) by flipping the FSEL bit. (For the dual flash mode only one NCS is needed.) Even if there is only one NCS signal, for most packages it can be routed to different pins, so by activating the proper alternate function setting, several flash chips (up to eight, I think, but check the load on the data lines) could be used without any external hardware. The not selected chips would be temporarily deactivated by setting the corresponding NCS pins to GPIO output mode and high or GPIO input mode with pull-up.

However, regardless whether you use these with an external decoder or the two NCS signals provided, if you want code execution from one of the external flash chips (in memory mapped mode), your firmware must access the 'data' flash by code in the internal flash and/or RAM only (and watch out for interrupt or DMA handling): when the 'data' flash is selected, the 'code' flash will be inaccessible and vice versa.

So, the simplest solution would be to use two similar flash chips in dual flash mode and memory mapped. This gives one uniform address space where you could place your code and data arbitrarily. But that's possible only if both flash chips are of the same type.

[Tesla DeLorean]

I haven't looked, but not sure the FMC address bus bits are exposed when accessing QSPI devices

For file system data, consider eMMC devices off the SDMMC/SDIO interface.

[MCadu]

I would prefer the board solution like Andreas described. What do you think about "concurrent" access? What happens if the code running in one flash needs to enter the second flash (file open, read, write...)?

[Andreas Bolsch]

If you use two flash chips with NCS1, NCS2 and select via FSEL bit, accessing the flash chip with the flash file system must be done from internal flash or RAM. Certainly your flash file system uses some low-level functions for read, write, erase sectors (sectors refers to file system sectors). These must be placed in the internal flash or RAM. And all interrupt handlers should go to the internal flash or RAM, too.

Reading a sector is then straight-forward as the read does not cause significant delays. For write and erase the file system flash should be selected only during command initiation, as soon as CS is deactivated (which starts the internal programming/erasing), the code flash can be selected again. Only for polling the flash (to check for program/erase completion) the file system flash has to be selected again. So concurrent use of both flash chips imposes only mild restrictions.

[MCadu]

So if I understand you correctly, I have to ensure that the LL functions still reside in the internal flash with for example the __attribute__ command?