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 · Accepted solution]

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

[DBurr]

If I change the .rodata section from ">FLASH" to ">RAM AT> FLASH" my code does not run. What I'm doing seems pretty straight forward, not sure why it won't run? Any ideas?

[TDK]

Can you share your code? A few possibilities:

• You're accessing something in flash, unintentionally. Functions typically access data. Is that data all in RAM?
• Another interrupt you're not aware of is accessing something in flash.

DCACHE and ICACHE shouldn't be affecting things, outside of speculative access, but I'd turn them off during debugging to eliminate that possibility.

Are any interrupts active during this process? If so, which ones? Is the vector table in RAM? Are the interrupt functions? Convince yourself and us that is the case by showing screenshots of the relevant registers. For example, set a breakpoint in an interrupt or a function you think is in RAM and examine the PC value. Look at SCB->VTOR and the values within to ensure they point to RAM.

[Pavel A.]

> If I change the .rodata section from ">FLASH" to ">RAM AT> FLASH" my code does not run.

Because .rodata is not in the area that is copied from flash to ram by the standard startup code.

While erasing the flash, try to disable any access to it (speculative or not) at MPU.