Engineer-to-Engineer Note EE-344
a
Technical notes on using Analog Devices DSPs, processors and development tools
Visit our Web resources http://www.analog.com/ee-notes and http://www.analog.com/processors o
e-mail processor.support@analog.com or processor.tools.support@analog.com for technical support.
Using the NAND Flash Controller on Blackfin® Processors
Contributed by Gurudath Vasanth Rev 1 – September 15, 2008
Introduction
Analog Devices Blackfin® processors are targeted to be widely used in many handheld products such as
PDAs, smart phones and PDA phones, digital cameras, and many other portable media devices. These
products usually store multi-media content such as movie clips, pictures, and music. NAND flash is most
commonly used for storing such high-density data. The processor’s NAND flash controller simplifies the
memory interface design and eliminates the need for external on-board glue logic. It also reduces the
overhead on application software and thus improves the performance to a large extent.
This EE-Note discusses the on-chip NAND flash controller (NFC) on ADSP-BF52x and ADSP-BF54x
Blackfin processors. It covers software driver development and the algorithms that are required to manage
the NAND flash memories. Example code associated with this EE-Note includes block erase, page
program, page read, random data input, random data output, and copyback operations in addition to
managing the bad blocks. The driver code is written for the flash devices from ST Microelectronics
available on ADSP-BF527 EZ-KIT Lite® and ADSP-BF548 EZ-KIT Lite boards. The EE-Note concludes
with guidelines to re-use the drivers for SLC NAND flash devices from other vendors. Appendix A
summarizes the differences in NFC between ADSP-BF52x and ADSP-BF54x processors.
NAND Flash
NAND flash is arranged as blocks, and each block contains many pages. For example, NAND02G-B2C
from ST Microelectronics used on the ADSP-BF548 EZ-KIT Lite board contains 2048 blocks, and each
block contains 64 pages. The page size is 2048 bytes of main area used to store data and 64 bytes of spare
area which is commonly used to store ECC, software flags, and so on.
Unlike hard disks, NAND flash memories can only be programmed one page at a time and they can only
be re-programmed after the entire block containing the page has been erased. Also, NAND flash has a
restriction of a limited number of erasures per block. Usually, the number of program/erase cycles will
vary from 10,000 to 100,000 times, after which a block is not reliable to store data. Due to these
constraints, a sophisticated algorithm is used to make the NAND flash appear to the system as an ideal
storage device.
life of the NAND flash devices. For more information on NAND flash memories, refer to
http://en.wikipedia.org/wiki/Flash_memory
Copyright 2008, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application of
customers’ products or for any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are property
of their respective holders. Information furnished by Analog Devices applications and development tools engineers is believed to be accurate and reliable, however
no responsibility is assumed by Analog Devices regarding technical accuracy and topicality of the content provided in Analog Devices Engineer-to-Engineer Notes.
This section discusses bad block management and wear leveling algorithms that extend the
[6]
.
Bad Block Management
Some of the blocks of NAND flash shipped from the manufacturer are marked as “bad” and some blocks
can become bad during the course of use. NAND flash driver code must recognize these bad blocks and
be able to avoid using them by the application software.
For example, on ST Microelectronics flash devices, any block where the 1st and 6th bytes (or 1st word, in
the spare area of the 1st page) does not contain 0xFF, is treated as a bad block. So, these blocks should be
identified first before any erase operation is performed. A table containing the information of invalid
blocks should be maintained. Any blocks that become invalid during the course of use should be updated
in the bad block table.
The associated code first checks for the existence of a bad block table. If it is not created, the code checks
for the invalid blocks marked by the manufacturer. This table is usually kept in block 0 as all the vendors
guarantee block 0 as a valid block. (Associated code provides users with an option to keep the bad block
table in any block). This table is loaded to internal memory for further updating when the erase/program
operation fails or when there is error in the error checking and correction (ECC) itself during a read
operation. Figure 1 shows the flowchart of bad block management implementation in the sample code.
Since the NAND boot starts from block 0, the bad block table in the associated code can be kept
a
in a block other than block 0, so as to evaluate NAND boot feature as well. By default, the table
is kept in block 5.
a
a
The NAND flash file system sample code provided with the VisualDSP++® 5.0 Update 4
development tools, by default, reserves a 10-block region at the start of the array, which is not
managed by the file translation layer. This is intended to allow the user to evaluate NAND boot
or for other purposes. Hence, it is recommended that users use this space to evaluate the sample
code provided with this EE-Note. Refer to the readme file of the NAND flash file system
example in the VisualDSP++ installation for more details.
Figure 1. Flowchart of bad block detection
Using the NAND Flash Controller on Blackfin® Processors (EE-344) Page 2 of 10
Wear Leveling
NAND flash has a special property in that any page to be written into a block must be erased. Usually, the
number of program/erase cycles will vary from 10,000 to 100,000 times, after which the memory cells
wear out. For write-intensive applications, it is recommended to implement a wear-leveling algorithm to
monitor and spread the number of write cycles per block. This way all the blocks will undergo an equal
number of erase cycles, thereby extending the life of the device.
There are many methods to implement a wear-leveling algorithm. The basic requirement is to spread the
number of program/erase cycles across all the blocks. For example, a round-robin method can be used to
select the physical blocks. Another method is to maintain a vector having the number of program/erase
cycles undergone by each block. The algorithm should map the virtual block to the youngest physical
block. A highly reliable system should implement a sophisticated algorithm to extend the life and data
retention of the device.
NAND Flash File System
Most of the portable and handheld systems require high density to store large multimedia files, and
NAND flash suits these applications. The main characteristics of NAND flash is that bits can be cleared
only by erasing a large block of memory, and each block can sustain a limited number of erase cycles.
Due to these limitations, the existing file systems cannot be used directly to support NAND flash.
Sophisticated algorithms must be used in file systems to overcome these limitations and effectively use
the flash memory. This can be achieved either by having a translation layer between the existing file
system and flash device to mask the differences, or by developing a customized file system to suit the
flash properties. A file translation layer would basically perform block-to-sector mapping, reclamation
(garbage collection), and wear leveling. This layer communicates with the low-level drivers which
includes ECC and bad block management.
a
Many file systems such as JFFS (Journaling Flash File System), JFFS2, and Trimble File Systems are
feasible to use with NAND flash. Among these, YAFFS (Yet Another Flash File System) by Aleph One is
only one file system that is designed specifically for NAND flash memories under any operating system.
It uses an efficient map structure to map file locations to physical address of NAND flash.
NAND Flash Drivers
This section discusses how to implement the basic drivers such as erase/program/read. The discussion
starts with an overview of NFC on ADSP-BF52x and ADSP-BF54x processors.
A Quick Look at NFC
The key features of NFC include:
Support for SLC NAND flash devices with page sizes of 256 and 512 bytes. Larger page sizes are
supported through software
Supports DMA transfer between internal memory and NAND flash device
Using the NAND Flash Controller on Blackfin® Processors (EE-344) Page 3 of 10