>>Where is flash stall discussed in the reference manual?
I don't know, but it's a common phenomenon I can date back until at least the early 1990's, perhaps late 1980's, related to NOR Flash implementation. So Established Lore
ST's solution is to use the Flash's "Busy/Ready" to stuff wait-states to hold off the processor, when something tries to touch flash memory whilst it is unavailable. One could perhaps have used a mutex/semaphore at a software level, for code running outside of the flash, but it's a coding nightmare to enforce, what with interrupts, blocking functions and libraries / call-trees no one is interested in understanding. An alternative would be for the MCU to fault, allowing for code to support a retry later, or defer to other tasks/threads, but most anything hard in the code is provided as a while(1) these days.
Have your entire core run from RAM, don't touch or look at FLASH whilst busy, and use a MUTEX/SEMAPHORE to control ownership access so the MCU doesn't have to use the "Ban Hammer" to enforce for you.
ST's failing here is stupidly large sectors, and erase times, relative to watchdog, and real-time service expectations of nearly every other peripheral. Could have been far better partitioned and banked in my opinion to contain the impact, but that takes design work, and transistors.
