cancel
Showing results for 
Search instead for 
Did you mean: 

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

JShih.2
Associate

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

1 ACCEPTED SOLUTION

Accepted Solutions

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
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

6 REPLIES 6
LCE
Principal

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 Employee

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 Accept as Solution on the reply which solved your issue or answered your question.

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
Up vote any posts that you find helpful, it shows what's working..
JShih.2
Associate

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

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
Up vote any posts that you find helpful, it shows what's working..
LCE
Principal

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.