Skip to main content
JShih.2
Associate
September 18, 2024
Solved

[STM32H7] external flash in Memory mapped mode with write access

Hi,

I'm working on the project using STM32H723 with an external flash (GFX02Z1), I'm moving the application code to that 8MB external flash on GFX02Z1, I saw the guidence mentioned that only read access after memory mapped enabled?

The reason I asked is that we will need to support firmware upgrade, so we may need to conside other solution if not have the write access after memory mapped mode enabled.

Please help to confirm, thanks.

 

Best Regards,

James Shih

This topic has been closed for replies.
Tesla DeLorean
Tesla DeLoreanBest answer
Guru
September 19, 2024

Even though the STLDR runs from RAM, the QSPI FLASH cannot be written whilst in Memory Mapped mode.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

6 replies

LCE
Principal III
September 18, 2024

You can always switch off memory-mapped mode and get back to regular (register CR, bits FMODE, called "indirect-write / read") SPI-like read / write mode, you just can't do both (mm / indirect) at the same time.

KDJEM.1
ST Technical Moderator
September 18, 2024

Hello @JShih.2 ,

 

Are you use the OCTOSPI interface for STM32H723?

It is mentioned in the STM32H723 datasheet section 3.18 Octo-SPI memory interface (OCTOSPI) that: "Memory-mapped mode: the external memory is memory mapped and it is seen by the system as if it was an internal memory supporting both read and write operations."

Also, in RM0468

KDJEM1_0-1726653597008.png

Note that, when doing memory-mapped writes, set the DQSE bit of the OCTOSPI_WCCR register, even for memories that have no DQS pin (please see STM32H72xx/73xx device errata - Errata sheet section 2.8.6 Memory-mapped write error response when DQS output is disabled.) 

KDJEM1_1-1726653778376.png

Please refer at these examples for write operations: OSPI_NOR_MemoryMapped_DTR and OSPI_HyperRAM_MemoryMapped.

Thanks and best regards,

Kaouthar

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.
Tesla DeLorean
Guru
September 18, 2024

You can't pretend QSPI Flash devices are RAM

You'll need to unmap via OSPI Abort, and do aligned page writes and wait, after you've done block erase and waits to clear the space.

The time domain issues and complexity here are inconsistent with the concurrent uses of XIP

You can update the content but you must switch operating mode.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
JShih.2
JShih.2Author
Associate
September 18, 2024

Hi,

Thanks for the response, but probably not clear to explain what I'm doing.

Right now I'm running my firmware in the external flash using QSPI memory mapped mode (0x90000000), in other words, my entire firmware is not in the internal flash (0x08000000).

All my QSPI configuration is in the STLDR project, not current running application project where QSPI isn't configured, so in this situation, can I still have the write access? If yes, how could I do it?

 

Thanks.

James Shih

Tesla DeLorean
Tesla DeLoreanBest answer
Guru
September 19, 2024

Even though the STLDR runs from RAM, the QSPI FLASH cannot be written whilst in Memory Mapped mode.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
LCE
Principal III
September 19, 2024

> All my QSPI configuration is in the STLDR project, not current running application project
> where QSPI isn't configured, so in this situation, can I still have the write access?

What's "STLDR project"? 

Anyway, maybe I don't know enough or understand what you want to do.

Do you want to write to QSPI only for firmware update, or do you want to use it also as "data eeprom"?

If firmware update only, that should not be a problem with the bootloader in the internal flash.