How _your_ MCU reacts on Flash read while writing can only be answered by the manufacturer (ideal: it can be found in the manual).
Common traps are enabled interrupts and the vector table still points to the flash.
The MCU by itself will not "decide" to fetch code from Flash. But be carefull to check that also all data needed is in RAM; not only the code!
I want to completely avoid use of Flash when writing or erasing it. All traps mentioned are already avoided. No data required is allocated in the Flash and interrupts are disabled completely for the Flash operations.
"The MCU by itself will not "decide" to fetch code from Flash." - I wonder on what basis I can be sure about that statement. Is it ARM core specific or manufacturer specific? Is it documented somewhere?
Thank you for your help.
I doubt that there will be someone with an guarantee.
But from my understanding, turning off caches and executing from RAM will prevent further read access. Maybe some data barriers are needed in case of any outstanding load.
Things could get a bit messy with branch prediction. It is possible for the cortex-M7 to speculatively prefetch instructions in other "Normal" memory locations due to misprediction. Normally, you won't see the abort or any issue because even if it caused a bus error response, it will not trigger fault exception if the instruction/data is not used.
Potentially you could use the MPU to force the flash address space to become a Device type so that speculative accesses should not take place. It is also possible for a flash interface IP / bus level logic to might block the read accesses during flash programming.
regards,
Joseph
Thank you for the valuable information!
I forgot to mention - you might also want to set the XN attribute in the MPU region as well.
Would it be enough to disable BTAC reads in the Auxiliary Control Register? Could the static branch predictor still cause similar trouble?