David Brook from HCC Embedded, discusses how to ensure optimal performance for NAND Flash on embedded MCUs using a trusted and reliable software layer


any low-cost 32-bit MCUs come with on-chip NAND flash

controllers that are used to interface external flash memory directly. NAND flash is arranged as a set of

blocks, each of which is divided into physical pages. Each page contains an area for data and a spare area that is used for NAND management data. It is increasingly common for NAND flash to consist of multiple planes that can be addressed independently and programmed or erased in parallel.

KEY DESIGN CONSIDERATIONS  Wear-leveling: Flash cells have a limited life and can only be erased and programmed a certain number of times before becoming unreliable – in effect, they wear out. Wear-leveling algorithms increase the life of the chip by moving the data between physical blocks to ensure some cells are not overused in comparison with others These algorithms can be fine-tuned to match performance requirements

 ECC: The worst-case rate at which wear occurs is defined by the flash manufacturer. Error correcting codes (ECCs) are used to ensure the data are always consistent if used within the chip specification. The strength (number of bits) of the required ECC is defined by the worst-case bit-failure rate

 Bad block management: Flash memory contains blocks that may be error-prone or unusable when the device is new. During operation, data in good blocks can later be corrupted by charge leakage or disturbance from writes in adjacent parts of the chip. Software manages bad blocks and maps unusable areas to ensure that data is not corrupted

 Read disturb: Read disturb errors occur when a read operation on one page causes one or more bits to change in other pages of the same block. Executing many read operations on pages within a block, with no intervening erase of that block, increases the risk that bit errors will develop Because of the requirement to re-map bad blocks, it is not possible to treat a NAND device as a linear array of memory in most applications. In applications

where flash is erased and re-written many times, wear-leveling must be introduced to increase the life of the device. Both these issues require a logical translation of the physical blocks. These problems are resolved by using a software-based flash translation layer (FTL). From an application perspective, the FTL presents an array of logical sectors that hides the underlying complexity of the physical device, allowing a file system to use it like any other media driver.

A FTL should also address the problem

of wear-leveling. There are two common approaches: static and dynamic wear leveling. In dynamic wear-leveling, the system chooses the least-used block for the next write operation. This method is relatively weak since it does not account for data blocks whose contents remain unchanged. With static wear-leveling, under-used blocks are swapped in to distribute the wear across the whole device. Static wear-leveling needs to be carefully tuned to ensure that block- swapping does not contribute to device wear. This is typically achieved using thresholds to determine sensible limits for swapping blocks.

FAIL-SAFE FTL REQUIRED FOR RELIABILITY In an embedded application, if the data (or meta-data) managed by the FTL becomes corrupt then the result could be potentially catastrophic. For example, a file system stored on the NAND flash may require reformatting and this will mean loss of all data as a consequence.


Fail safety system requirements: No file system can claim to provide fail-safety on its own; a system wide design is required

For this reason, a fail-safe FTL must be used where the data is valuable and the application is required to be reliable. A truly fail-safe FTL will guarantee that all meta-data it manages on flash will always be consistent and that any write to flash by an application (typically a file system) will be completed atomically. The atomicity of a write means that either the write operation is completed or the disk is left in the same state as it was, prior to initiation of the write. This means the FTL can guarantee the integrity of the data passed to it by the file system. To ensure a fully fail-safe embedded system (Figure 1), each layer from the application level to the physical driver must specify what it requires from the adjacent layer. For example, a generic FAT file system would require multiple writes to different areas of the media to be completed atomically. This is logically impossible to guarantee on a system where unexpected resets may occur. To build a reliable application, a fail-safe file system can be used together with a fail-safe FTL.

POWER MANAGEMENT HELPS ENSURE DATA INTEGRITY Designers should also use careful power management to ensure the flash device is not erased or written when power levels are outside of the manufacturer’s specified limits. If this is not the case, then problems with the integrity of blocks and data may occur. A well- designed FTL will specify the requirements of the low-level driver, including power requirements, to ensure fail-safe operation. Designers should request these specifications from the software supplier. For example, when the voltage supply falls to the specified minimum, then brown- out detection should notify the system so that this condition can be managed. Designers should be aware that

reliable embedded flash-based systems require careful attention to detail at both system level and low level. This is the only way to ensure a high-quality, stable application.

HCC Embedded e:


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44