Flash Dual Bank in STM32F2 & F4 ?

Some STM32F1 MCUs have Flash Dual Bank, provided total amount of Flash is bigger than 512 KB. Thanks to that they posses valuable ability to "read-while-write" (RWW).
Do MCUs from STM32F2 or F4 series have this feature? Or they have to stall for more than a second just to erase a Flash sector (128 KB one)? And to miss the watchdog refresh as a side effect too?

And yes the part can stall for well over a second (64 KB 1.4s max, 128 KB 2.6 s max) to erase. You do however have plenty of RAM, which runs faster than FLASH in any case, put your code there. And yes your watchdog will be a problem.

Yes, I pressed them on this point at the seminar I attended. I went to one after Frank here had observed a large chunk of RAM (CCM Tightly Coupled) was unavailable to DMA.

I pointed out that the way they had configured FLASH with the long potential stalls had made the feature close to pointless, this is then further compounded by the huge sector sizes, and long erase times. ST has missed an opportunity to differentiate the part from the competition by not having multiple banks or planes within the FLASH. Guys can we please think about how people need to utilize these parts in the field, and the fact a lot of people need to be able to upgrade via network or wireless connections, the CPU seizing up for second(s) is not something that can be worked around easily.

Supplying an external VPP can speed things up, but this isn't terribly practical.

I've used FLASH parts that don't permit any reading in the past, so I've typically used the RAM base approach. Another is to pre-erase storage during initial boot, prior to running the primary application, and also performing upgrade/copy operation there. The stall time is then at least just the word write time.

I think the most practical solution with the current design is to have some large SRAM or NOR FLASH device on the external bus.

Another thing ST should consider is much larger internal SRAM, yes I know the cells are bigger, but then the FLASH code could be compressed, and all the complicated ART stuff to mitigate the ~30ns access time could also be dumped.

Thanks for the interesting points in this lengthy review.
The idea of pre-erasing sectors during boot process is new for me and seems quite fruitful.
I'm going to attract STM's attention to this topic on next seminar too.
In our current project we would like to use internal Flash instead of external EEPROM to store datalog. Usage of ext memory is a waste of money and pcb's space. Can't even imagine how could I utilize whole 1 MB of Flash just for my code? What such huge should I implement to fully use it?

Yes, been using the STM32F1's FLASH to log data. Seemed appropriate and should support once a day erasure for at least a decade.

Generally would recommend a rolling algorithm to level wear across the available space, marking pages as defective as needed and strategically erasing at reset. ie when exiting STANDBY, or cold starts.

Things like journalling might also be appropriate to reduce erase cycles.