I CANNOT WRITE DATA TO EXTERNAL FLASH WHILE STM32H750 TOUCHGFX IS RUNNING

[MKoca.1]

STM32H750 EXTERNAL FLASH WRITE DATA PROBLEM

Hello everyone,
I am working on a TouchGFX project using STM32H750. In order for the program to be executed, I started the program on the external flash at address 0x90000000 using the bootloader. My project works perfectly for now and I can do everything I want via TouchGFX. I use a 10.1 inch screen. I use MT25QL512ABB8ESF as an external flash and IS42S32400F-6TL as an external RAM. My real problem starts from here. In the later stages of the project, I want to write different data to the external flash whenever I want. And I also want to update the application via WiFi or USB. In order to do these, I need to be able to write data to the external flash while TouchGFX is running. I haven't figured out how to do this yet. Can you help me with this?

[Tesla DeLorean]

It's going to be a challenge, as you can't concurrently memory-map / XIP and send commands and stall for erase and writes.

You'll need to create a subsystem that runs under Internal Flash, or RAM

Can you stage to something else, like MicroSD / eMMC or secondary SPI attached NOR FLASH, or NAND FLASH

If staged you can deal with updates at start-up before running the main application.

Perhaps if you don't memory-map, and rather use the QSPI as a Flash File system, pulling image data via RAM as needed. You'll need to look at different modes of operation TouchGFX can use to load/resource. Or an update screen where very limited functionality the suspends memory-mapped operation.

[MKoca.1]

Thank you for your quick response, sir.
Frankly, I have come across a few topics on the forum about writing data to flash in a very limited functionality state that disables interrupts and suspends memory-mapped operations. At least the application update can be done this way, I can lock the update screen and block the user until the update is finished. However, I could not figure out how to program a very limited functionality state that disables interrupts and suspends memory-mapped operations. An example of this would be very useful.

[Tesla DeLorean]

>>An example of this would be very useful.

I'd imagine, perhaps you can get the ST / TouchGFX team, or your FAE to work on that.

Another alternative via USB, is that you come up a solely a USB MSC, and a portion of the QSPI FLASH can be provided to be a FLASH DRIVE so the user can drag-n-drop update files, which can be processed once the drive is disconnected.

[MKoca.1]

Thanks for your suggestion, I will discuss this with FAE.

Can you elaborate on your suggestion about USB?
Can I drag and drop update files while QSPI Flash is running in Memory Mapping mode?
How can I provide a portion of QSPI Flash as a Flash Drive?
Should I write the USB related code to internal memory or external memory?

[Tesla DeLorean]

You'd commit a portion of the QSPI NOR to be 4KB sectors managed via USB MSC Read / Write routines.

Like I said you can't concurrently use Memory-Mapped mode, and interact at a command level. Writes and Erase, also take time to complete, whilst you want for the operation to finish before sending the next command.

The memory-mapped mode use a READ command template, in to which it inserts the Address that data will come from. The memory can only deal with one command at a time, and can be busy with other operations.

You'd want your USB MSC functionality to run from Internal FLASH, or RAM, notionally you could implement in your boot loader, prior to handing off control to your application code.