cancel
Showing results for 
Search instead for 
Did you mean: 

External QSPI NOR flash read and write operation

JonConesa
Associate III

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!
3 REPLIES 3

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. 

 

 

Saket_Om
ST Employee

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

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
Saket_Om
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.