Using NAND Flash for Run-Time Code

Maybe it's the applications, maybe it's time-to-market constraints, and maybe it’s just sloppiness, but code-smiths seem to require more and more program, data, and scratch memory to implement both simple and complicated functions. In some cases, it is understandable. A GPS needs a lot of map data and that takes up NOVRAM space. However, in other cases, it seems like bombs are being used to kill ants with 1 Mbyte of Flash in an embedded MCU provided to handle simple I/O control functions.

NOR Flash is the standard for bus-tied, parallel-interfaced, code-partitioned memory. In contrast, NAND Flash has grown to be the industry workhorse for data storage not directly related to executable code.

This article looks at three approaches that higher-end MCUs use to allow NAND Flash to hold boot code and firmware. Some are just programmed I/O. Some have direct support for NAND Flash through on-chip hardware interfaces and some support the process through smaller, on-chip boot loaders. The smaller, low-cost boot loaders in NOR Flash can still allow the micro to access vast amounts of code and data space, cache it into RAM and operate, often faster than NOR Flash bus tied memory since it may not need wait states. All parts, datasheets, reference designs, tutorials, and development systems referenced here can be found online at DigiKey’s website.

Challenging the standard

Even with many MCUs offering memory management units (MMUs), indexing, and pagination functions, the pool of memory directly accessible from any micro is a linear block addressed directly by the binary value of an address bus. NOR Flash supports this architecture directly and is the workhorse for fetched nonvolatile code and data (Figure 1A).


Figure 1A: Standard NOR Flash, like RAM, is a contiguous block of linearly-addressed memory locations.

In contrast, NAND Flash is organized like a hard disk. Contiguous blocks of data clumped together form sectors that are addressed in tabular fashion like the file operating systems on a disk drive (Figure 1B).


Figure 1B: NAND Flash uses the same data bus to address the individual sectors inside. Entire sectors must be read-in or written-out at one time.

This does not allow a NAND Flash to be used to boot and run code like a NOR Flash does. It is not a random-access memory (RAM). Instead of being able to access or modify individual memory locations, the entire sector must be read-in, updated, and written-back. This slows down performance even more when code execution jumps around. Each time an access outside the cached block takes place, everything halts while the micro reads-in a new entire sector. What could take place in a single high-speed micro cycle using NOR Flash now requires much more time since the entire block must first be accessed and then cached into RAM.

NAND Flash, however, does have advantages over NOR. First, it has higher endurance (typically 1 million writes compared to 10K or 100K write cycles that NOR Flash provides). Having said that, it should be noted, modern NOR Flash is getting better all the time. A second advantage is that even though an entire block needs to be read-in and written-back, the streaming operations overall are faster. Once set up, each location is clocked in or out at high speed, faster than the address-decode-fetch cycle required for each access of a NOR Flash. As a result, overall, NAND Flash devices have reduced read and write times for moving a lot of data.

Thanks to the ever increasing density and speed of volatile RAM such as SDRAM, DDR, DDR2, and DDR3, plenty of lower-cost high-speed nonvolatile memory is at the ready for caching purposes. This can dramatically reduce the amount of conventional NOR Flash required since only a basic boot loader is now needed.

We can now architect our system to place a NAND Flash on our circuit board (or a plug- in NAND Flash memory card). Then, when the micro boots up, a small, low-cost, on-chip NOR Flash-based boot loader can cache code and data into the lower-cost pool of contiguous, linearly addressable RAM. While operating the task at hand, data as well as dynamically-loaded code can be pumped to and from RAM when needed.

Some examples

One option is to use a standard microcontroller with a small amount of internal or external NOR Flash. Often, families of microcontrollers come in ROMless flavors that use external bus interface for all accesses. On-chip Flash sizes can vary from a very small block to very large blocks. As you would expect, smaller block parts are less expensive and ROMless parts are even cheaper. A system designer can lower costs with smaller block parts, especially if deep external pools of NAND Flash can be used.

NXP takes this approach with their LPC2200 family which comes in the ROMless (LPC2220FBD144,551) flavors with 128K Flash on-chip such as the LPC2212FBD144/01,5 and 256K Flash such as the LPC2292FET144/01,5. Since no dedicated NAND Flash interface hardware exists inside these 16/32 bit 75 MHz ARM® 7 processors, NXP shows engineers how to use two general-purpose I/O lines along with one External Memory Interface (EMI) bank. In this case, either on-chip Flash or a small external ROM holds the boot-loader and code controls the process of extracting and verifying the data from the NAND Flash.

I used italics here to underscore the importance of verification since NAND Flash may have defects and become stuck at certain locations. NOR Flash on the other hand is typically more reliable and defect free. This means that Error Detection and Correction on NAND Flash must be coded into the access and loading of critical code and data. Typically, only the zero page of a NAND Flash is guaranteed to be defect free.

NXP illustrates the technique for hardware implementation and code generation for this application with an applications note (AN10600).¹

STMicroelectronics also has a generic applications note (AN1935) that can be used with the ST family of Microcontrollers, or with virtually any microcontroller. This app note shows how to boot from external NAND Flash memory using block zero with Small page (528-byte/264-word) or Large page (2,112-byte/1,056-word) single-level-cell NAND Flash memory devices (Figure 2). Note here how ECC is directly supported to verify integrity of the data.


Figure 2: A small internal ROM holds boot-loader code, which transfers run-time firmware to external RAM (DRAM in this case). Note the need for ECC in the boot-block code since NAND Flash can have defects.

Adding on-chip functionality

Realizing the benefits of NAND Flash, microcontroller suppliers are integrating direct NAND Flash support in their MCUs in several ways. Their aim is to provide the best of both worlds to embedded designers. One way is to use a small boot loader on-chip and either use programmed I/O, or dedicated on-chip hardware for the NAND interface.

This is the approach taken by Atmel with their AT91SAM7SE which is a 32-bit ARM Thumb-based microcontroller using the ARM 7 architecture. It is a member of the company’s SAM7SE series. The 144-pin 5 MHz controller has 88 I/O and holds 32K x 8 of on-chip Flash. This is a middle-of-the-road processor with a good amount of horsepower for many general-purpose tasks, and it would seem starved for code space with only 32K if it were not for the on-chip NAND Flash interface.

The external bus interface on the Atmel parts supports high-speed, single-cycle SDRAM, as well as glueless connection to Smart Media, Compactflash, and ECC-enabled NAND Flash devices. While versions with up to 512K on-chip are available, for cost-control purposes this 32K part is more than enough to hold a boot loader and take advantage of the on-chip hardware interface for 8- and 16-bit NAND Flash devices (using one of its on-chip device decode sections (Figure 3).


Figure 3: The Atmel micros use an external interface that connects to the NAND control and data lines without any glue or external logic. Shown here is a 16-bit-wide interface, but these parts also support an 8-bit-wide interface.

In-circuit emulator (ICE) support for the Atmel parts is provided by the JTAG-based AT91SAM-ICE development tools. The Equinox Technologies FS2009USB(ARM) in-system-programming tools are also available for test, debug, and the manufacturing environment.

A second solution

Another approach is to implement on the micro a sequencer or state machine that transfers contents of a NAND Flash automatically to RAM when the micro boots. This approach is taken by Freescale Semiconductor with their 400 MHz 32-bit MPC5125YVN400, well suited for complex and real-time tasks. What makes this part interesting is that it is ROMless with no Flash at all. Instead, it allows booting from an external NAND Flash device through its on-chip NAND Flash controller (Figure 4).


Figure 4: When dedicated NAND Flash interface logic is integrated inside the Freescale MPC5125 micro’s multi-port memory controller, the contents of NAND Flash can be transferred to high-speed RAM automatically when the micro boots.

These parts have a flexible, multifunction memory-bus interface that not only supports DDR1, DDR2, and low-power DDR (LPDDR) interfaces, but also has an embedded NAND Flash controller on-chip that supports NAND Flash in its MMC, SD, and SDIO formats. The internal controller supports 8- and 16-bit wide NAND Flash devices and can boot from devices with a greater-than-2-Kbyte page (or sector). Once booted, it supports 512-byte, 2-Kbyte, 4-Kbyte, and 8-Kbyte sector sizes with a built-in error correction and detection engine.

Note the higher-end peripherals like USB OTG, Ethernet, and TFT display interfaces. These can be code and data intensive. A perfect application for the higher densities of NAND Flash is to hold graphics page templates and blast them to the display quickly using the on-chip DMA controller. This is much faster than having to use code time to crunch and render the graphics and can make a real difference in display and image quality. The extended temperature range from –40° to +125°C makes this MCU an ideal candidate for automotive applications as well; especially with its built-in multiple CAN interfaces.

In summary

Virtually any micro with enough I/O can talk to NAND Flash, and via their development kits most micros demonstrate this with support for the various flavors of NAND Flash memory cards including USB, Smart Media, SD, Compact Flash, Micro SD, Secure Digital, and others.

While accessing the data is one thing, being able to boot and run is a bit trickier. The three approaches outlined here are a good starting point for your embedded designs if you have the need or desire to use NAND Flash.

Finally, remember that NAND Flash, even though it has high endurance, can have defects that occur in normal use, so wear leveling, error detection/correction, sector lockouts, and other system integrity tools should be coded into your application.

References

1. NXP app note AN10600: “Connecting NXP ARM-based microcontroller LPC2200 to small page NAND Flash”