STM32F7 running code from RAM and erasing flash simultaneously

[DBurr]

Hi, I've got an application which is running on an STM32F746ZGT. During in the field firmware upgrades, it has to erase part of the device's internal flash memory and then write to the flash. The problem I'm trying to overcome is to enable the device to continue executing code during the erase operation, which takes around 5 to 6 seconds. To do this, I'm moving some of the code chunks that I want to keep running during the erase operation into RAM. There's an interrupt and also the ISR vector that I'm moving into RAM. I'm following this example: https://community.st.com/t5/stm32-mcus/how-to-place-and-execute-stm32-code-in-sram-memory-with/ta-p/49528 It involves adding a ".RamFunc" section to the linker script. The issue is that so far I haven't been able to get code to continue executing during the flash erase process. I'm wondering if erasing flash will block the CPU from executing code, even if it's executed from RAM. Any advice would be greatly appreciated.

Thanks,
Doug

[TDK]

If the cpu attempts a flash read operation while the erase process in in progress, the cpu will block until the erase is complete.

If you have code entirely in RAM, it will continue to run. However, be aware that any constants that code refers to that it needs to read from FLASH will cause it to block. Probably what is happening here. Also be aware of speculative reads that may be occurring, or cached accesses, or interrupt routines still in flash.

[DBurr]

That sounds like a pretty good explanation, I'll have to move more parts into RAM. Ideally I could move all code and constants into RAM, but my code is just a little larger than the available RAM.

Would you recommend turning off instruction and data caching too?

Thanks,

Doug

[Pavel A.]

> If I set up the MPU to protect against access to flash before I erase the flash, won't that block me from erasing it?

It should not, as the command to start the erase is written to the flash control registers, not to the flash data area.

> And what will protecting against access to flash do to help with this issue?

Blocking access to flash data area in MPU should prevent any interference from the CPU, including the notorious speculative reads.

 

[DBurr]

Thanks for the suggestions. I've been stepping through the code, and I'm realizing that there's a huge chain of functions that also need to be moved to RAM in order for this to work as I want it to. That's where I'll focus now.