2022-03-21 07:02 AM
Hello, I'm using stm32f469 with QSPI external flash. The flash is divided for TouchGFX graphic data and for File System.
TouchGFX uses memory-mapped mode to access data, while File system accesses also in command mode.
How could I prevent TouchGFX to access the external flash while flash is configured to command mode?
Thank You,
Ari
Solved! Go to Solution.
2022-03-21 11:37 AM
This may not solve all your answers and two banks of flash is definitely easier (if it is feasible for you), but you can stop touchgfx, exit mem mapped mode, write/erase, enable mem map, and resume touchgfx in ~25ms. The biggest downside will be having to split up all file system stuff into smaller chunks to prevent obvious lag. Also from testing, only the qspi/ospi peripheral needs aborting, the peripheral and flash IC does not need to be reset (at least in my setup) saving a lot of time
2022-03-21 09:18 AM
It's an MCU, not MPU, fixed the tags for you.
Well No, you can't use the QSPI in Memory Mapped and Direct modes. What you might be able to do is create a resource model where you load data, via RAM or direct commands reads, and then also use the memory for a file system.
The STM32 is architecturally awkward in this regard, and the QSPI NOR memories don't really provide for threaded operation, as write/erase to NOR is rather slow, and blocks the read access whilst such operations are occuring.
Consider TWO banks of QSPI on different chip selects.
2022-03-21 09:33 AM
Thank you for response and tax fix.
I wonder if TouchGFX architecture reads all assets that are stored in flash via TouchGFXHAL::blockCopy().
If so, I could use a mutex object to synchronize between file system and TouchGFX.
The file system default mode is memory mapped. Only when required, it moves to command mode and then back to memory mode. The file system can lock access to NOR device while in command mode,
and blockCopy() will use this Mutex.
Do you think it could work?
Thanks
2022-03-21 09:34 AM
oops tag not tax ;)
2022-03-21 09:52 AM
I'm not a TouchGFX expert, but better windowing implementations allow for resources to be fetched piece meal, and not memory-mapped, or copied to another memory whole sale.
For example on platforms supporting SPI flash which isn't memory mapped. Or NAND based ones where the blocks have to be fetched individually.
Switching between Memory Mapped mode and Direct Access is slow and cumbersome, basically requiring the interface to be reset, and then both interface and memory configured coherently.
If you want file system to operate concurrently over several threads, then use would likely need a mutex or semaphore. The resources could be in a file, this might be more portable than allocating a fixed block/portion of the memory.
2022-03-21 10:16 AM
Thank you Tesla!
Any TouchGFX expert around?
I would like to know if TouchGFX reads data of all constant assets via a single interface function?
Or they are accessed directly?
When is the TouchGFXHAL::blockCopy() used?
Thanks.
2022-03-21 11:37 AM
This may not solve all your answers and two banks of flash is definitely easier (if it is feasible for you), but you can stop touchgfx, exit mem mapped mode, write/erase, enable mem map, and resume touchgfx in ~25ms. The biggest downside will be having to split up all file system stuff into smaller chunks to prevent obvious lag. Also from testing, only the qspi/ospi peripheral needs aborting, the peripheral and flash IC does not need to be reset (at least in my setup) saving a lot of time