Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
5 years, 8 months ago.
On-board flash write speed
Hi,
in my Mbed OS application, I'd like to write some data to the on-board flash using Flash IAP on my Nucleo-F767ZI.
So far everything works fine but I've noticed that writing to flash is extremely slow (even slower than writing to a micro SD card at default 1MHz connected via SPI). I understand that a sector needs to be erased before writing into it but, once this is done, what makes writing so slow (around 7x slower than writing to SD card).
Is this just a hardware limitation, i.e., flash is not intended to be re-written at run time?
2 Answers
5 years, 8 months ago.
The NAND type is found essentially in memory cards, USB streak drives, strong state drives (those created in 2009 or later), and comparable items, for general stockpiling and exchange of information. NAND or NOR streak memory is likewise frequently used to store design information in various computerized items, an errand recently made conceivable by EEPROM or battery-fueled static RAM. One key hindrance of blaze memory is that it can just persevere through a generally modest number of composing cycles in a particular square
Ref: https://laustan.com/index.php
5 years, 8 months ago.
Writing to flash is slow. The erase is slow, the programming is also slow. This is a fundamental feature of the way the internals of the flash chip work and the transistor design used in the chip. There are lots of different way of making silicon chips, they all have their own advantages and limitations.
An SD card or similar is built using a process that is designed and optimized for creating large fast flash memory blocks. Because flash is basically lots of rows of identical parts they can push the limits and risk a few parts of the chip not working. e.g. If you need 20 rows of memory for the chip size you are making you build a chip with 22 rows, as long as at least 90 % of them work you still have the 20 good rows that you need. They use the same technique for RAM, FPGAs and any other chip type that has lots and lots of identical parts. I've never looked into it but I wouldn't be surprised if GPUs with their thousands of parallel pipes did the same thing too.
A microprocessor on the other hand involves a lot of compromise, you have RAM, flash and logic all in one part. RAM and flash can both have redundancy but would ideally use very different production processes with different transistor designs. Logic on the other hand can't have redundancy, if you have one bad transistor in the middle of your processor then the whole part is junk. That implies some very different transistor designs and manufacturing processes.
The flash on a microprocessor is not normally written to very often when running but it does need to have very fast random read times, the CPU will be running code out of different memory locations and jumping around a lot. The random access read time of the flash in the micro will generally be far better than in any SD card.
Ultimately it's a compromise. You get flash with a good read speed built using a process that can also be used for logic and RAM. If that means the flash write speed is low then so be it, that's considered an acceptable trade off.
I've been doing some research regarding "Flash". The on-chip flash in the STM32F7 (and probably MCUs in general) is NOR-Flash while the type of flash found in other devices (ready for storage in the orders of GB) is type NAND-Flash.
Due to its hardware design, NOR-flash enables very fast random reads (since there's data path to all data cells). However, writing to it is slow and requires the erase of the entire sector before over-writing the data. So, the results I've been getting are as expected.
More info about NOR-Flash vs NAND-flash can be found here: http://aturing.umcs.maine.edu/~meadow/courses/cos335/Toshiba%20NAND_vs_NOR_Flash_Memory_Technology_Overviewt.pdf
posted by javier fernandez 08 Apr 2019