Flash Dual Bank in STM32F2 & F4 ?

Posted on April 11, 2012 at 15:51

The STM32F2 has 1MB under a single bank/controller.

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.

The 2MB STM32F4 isn't available until 2012 Q3, it might have two banks, speak to you local ST rep or FAE.

http://www.ebv.com/fileadmin/products/Products/STM/STM32F4_Series/STM32_F-4_Series_marketing_presentation_Customer_presentation_.pdf

Posted on April 12, 2012 at 08:41

Thanks clive1 for the prompt answer.

Let's hope next-gen F2 & F4 will have two banks/controllers. Because 128+64 KB of SRAM is not too much for a program plus data.

Posted on April 12, 2012 at 12:34

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.

Posted on April 12, 2012 at 13:10

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?

Posted on April 12, 2012 at 18:11

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.