Posted on April 12, 2012 at 12:34Yes, 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.
