External QSPI NOR flash read and write operation

[JonConesa]

Hi, 

I’m working on a custom board based on STM32H757BITx using an external NOR flash Micron MT25TL01GBBB8ESF-0AAT TR (Dual bank with Quad Lines)

Current usage

At the moment, the external flash is mainly used to store UI assets (images/fonts/etc.) for a display. I’m not using the full flash capacity, so I’d like to use an unused region to store a small persistent structure (configuration/status/log header).

To keep things organized, I created a partitioning scheme using the linker file, reserving separate address ranges:

• UI assets region (read-only at runtime)
• User structure region (needs occasional write/erase/program)

How it’s configured right now

Since up to now I only needed runtime reads, the flash is configured in Memory-Mapped Mode (DTR, QPI). I enable it with:

MT25TL01G_EnableMemoryMappedModeDTR(&hqspi, MT25TL01G_QPI_MODE);

This works great for reading UI assets through the mapped address space.

 

Problem

I now need to write into the user structure region, but I understand that in Memory-Mapped Mode the peripheral is configured for read transactions and typical write/erase operations require switching back to indirect mode (command mode).

Questions

1. Is it safe / supported to temporarily exit memory-mapped mode, perform:

   • sector erase (as needed)
   • page program for the structure and then re-enter memory-mapped mode (DTR/QPI) again?

2. If yes, what is the recommended sequence on STM32H757 to exit memory-mapped mode cleanly?
   For example: abort memory-mapped, re-init, switch to indirect, do erase/program, then enable memory-mapped again.

3. RTOS (ThreadX):
   Even though only the CPU reads the memory-mapped region (no LTDC/DMA2D direct reads from external flash), I have multiple threads. While one thread is writing to flash, another thread might try to read UI assets (mapped reads).

   • Is a mutex/semaphore around any access to the memory-mapped region the right approach?

4. Cache coherency:
   When returning to memory-mapped mode after writing, do I need to do DCache clean/invalidate.

Please find attached the source files containing the functions that access/call the external flash.

 

If anyone has done something similar,  I’d love to hear best practices.

 

Thanks!

[Ayoub Cheggari]

Hi,

I tried that once for HMI also and it didn't work very well!

Yet, you can try this sequence:

All NOR driver and QSPI should be put in RAM.

1- Disable Interrupts 

2- Stop scheduler (suspend)

3- Do erase/write (You should use QSPI in polling)

4- Activate MMM

5- Enable Interrupts

6- Resume Scheduler

It worked very well but wasn't stable! Sometime I get hard faults. My solution was to use an SDRAM. 

 

 

[JonConesa]

Thank you for the reply.
I’ll review the options and decide which approach is best. In my case, using the MCU’s internal flash seems like the safer choice.

 

 

[Saket_Om]

Hello @JonConesa 

Yes, this is the correct approach: temporarily exit memory-mapped mode, perform erase/program in indirect mode, then re-enable memory-mapped mode.

With ThreadX, you should serialize all external flash access using a mutex and ensure no other thread reads the mapped region while a write is in progress.

Please refer to the example below:

STM32CubeH7/Projects/STM32H745I-DISCO/Examples/QSPI/QSPI_MemoryMappedDual at master · STMicroelectronics/STM32CubeH7