NAND Flash Memories Application Note

NAND Flash Memories

Understanding NAND Flash Factory Pre-Programming

Schemes
Application Note
February 2009
an_elnec_nand_schemes, version 1.00
ersion 1.00!02.2009 "a#e 1 o$ 20
NAND Flash Memories Application Note
NAND $lash technolo#y enables memory manu$acturers to produce memory devices %ith hi#h density at
lo% cost. From that reason, NAND $lash memories are very popular in various electronic e&uipments that need to
store a lar#e amount o$ data, such as music players, cameras, mobile phones, "DAs and many others.
'here are several important di$$erences bet%een (traditional) N*+ and NAND $lash memories, %idely
discussed throu#h %orld,%ide,%eb articles and $orums. 'he most evident one is the presence o$ invalid bloc-s in
NAND $lash memory device. .t means that not %hole device address ran#e can be used $or data stora#e. /ome
memory locations are de$ective and cannot be pro#rammed and read reliably. 0o%ever, these de$ective locations
don1t a$$ect the reliability o$ the rest o$ memory device.
'here must various precautions been ta-en into account to cope %ith that de$ective locations, already in
development phase o$ the tar#et product. 'he set o$ such precautions can be called 2pre,pro#rammin# scheme3.
'his application note tries to e4plain all aspects o$ NAND $lash $actory pre,pro#rammin#. "lease, read it care$ully
be$ore you contact us as and as- $or special support $or your NAND $lash pro5ect. .t %ill help you to provide us %ith
all in$ormation that %e need $or success$ul implementation, in e4act and accurate $orm. 'his %ill help us to
implement your needs in as short time as possible, that %ill $urther reduce your pre,production costs.
ersion 1.00!02.2009 "a#e 2 o$ 20
NAND Flash Memories Application Note
A brief introduction to NAND flash
'he $lash memory %as invented by Dr. Fu5io Masuo-a in 1967, %hen %or-in# $or 'oshiba. .ntel %as the
$irst %ho has reco#nised massive potential o$ ne% technolo#y and introduced the $irst commercial N*+ type $lash
memory device in 1966.
N*+,based $lash memory has lon# erase and %rite times, but has $ull address ! data inter$ace that allo%s
random access to any memory location. 'hese properties ma-e it a convenient %ay $or stora#e o$ a pro#ram code
that doesn1t need to be updated $re&uently, such as a hand,held device $irm%are or computer 8.*/.
First NAND,based $lash memory device %as introduced by /amsun# and 'oshiba in 1969. .ts .!*
inter$ace allo%s only se&uential data access, ho%ever, the memory has $aster erase and %rite times, hi#her density,
lo%er cost,per,bit than N*+ and ten times the li$etime. 'hese properties ma-e it suitable $or mass,stora#e devices
such as memory cards ($or "9s, cameras, etc.) or actually boomed solid hard,discs.
Fi#ure 1 compares the memory cells o$ NAND and N*+,based $lash memories.
ersion 1.00!02.2009 "a#e : o$ 20
Figure 1. NAND versus NOR flash memory cell comparison (by Samsung)
NAND Flash Memories Application Note
Fi#ure 2 sho%s an internal or#ani;ation scheme o$ real NAND $lash memory device. 'he main attributes
are as $ollo%s<
8ytes are or#ani;ed into pa#es. *ne pa#e consists o$ data bytes area (typically multiple o$ =12)
and spare bytes area (typically multiple o$ 1>). 'ypical pa#e con$i#urations are =12?1>, 2076?>7
and 709>?126 bytes. Data area is used $or stora#e o$ payload data (e4ecutable code, photos,
M":s, etc.), %hile spare area is used $or memory mana#ement purposes (bloc- validity labellin#,
operatin# system $la#s, error recovery data, etc.). 'he spare area is not included in device capacity
and cannot be directly addressed. 'he pa#e comprises the smallest pro#rammable unit.
/everal subse&uent pa#es (typically :2, >7, 126 or 2=>) comprise a bloc-. 'he bloc- represents
the smallest erasable unit. .$ any de$ective bit is $ound, respective bloc- is declared bein# invalid
and e4cluded $rom $urther use.
/ome amount o$ bloc-s comprise a lo#ical unit (@AN). 'he memory device can contain one or
several @ANs (mainly modern NAND $lash devices). @ANs improve memory per$ormance by
introducin# some level o$ parallelism, but are not in concern durin# $actory pre,pro#rammin#.
'he memory is accessed via data re#ister. /ome memory devices use also parallel cache re#ister that
improves data throu#hput by utili;in# device busy time durin# internal data trans$ers.
Data re#ister utili;ation<
+ead operation< A$ter con$irmin# the read command, internal data trans$er $rom memory array to
data re#ister be#ins. Durin# the trans$er, the device is in busy state. A$ter the trans$er completes,
the host can read the data $rom data re#ister in se&uential manner.
"ro#ram operation< Firstly, the host must upload the data bein# pro#rammed to data re#ister. A$ter
con$irmin# the pro#ram command, internal data trans$er $rom data re#ister to memory array
ersion 1.00!02.2009 "a#e 7 o$ 20
Figure 2. An 1!bi" NAND flash memory archi"ec"ure e#ample (by $icron)
NAND Flash Memories Application Note
be#ins. Durin# the trans$er, the device is in busy state. A$ter the trans$er completes, the host can
continue pro#rammin# other pa#e.
'he errors can occur durin# both, pro#rammin# as %ell as read operation. 'ypically, multi,level cell NAND
$lash devices are more predisposed to error #eneration due to more complicated cell structure %ith more vulnerable
thresholds. Moreover, error in one memory cell can a$$ect t%o or more pa#es. 'o %or-around the problems %ith
NAND $lash reliability, the host typically uses<
$or pro#ram operation< various invalid bloc- mana#ement techni&ues
$or read operations< various error detection and recovery mechanisms
An invalid bloc- represents a special -ind o$ NAND $lash memory device error. .nvalid bloc- contains
permanently de$ective bit location(,s) that cannot be reliably pro#rammed ! read. .nvalid bloc-s can arise in t%o
di$$erent %ays<
Durin# the manu$acturin# process at $actory (inherent invalid bloc-s). 'hese invalid bloc-s are
discovered durin# $inal tests. 'ypically, such bloc-s are disconnected $rom po%er line and cannot
be accessed (not pro#rammable, read as all 0400). *$ten, they are 5ust labelled bein# invalid usin#
some invalid bloc- labellin# scheme speci$ied by manu$acturer (or by *NF. #roup , see
http<!!%%%.on$i.or#). .nherent invalid bloc-s must me reco#nised and treated durin# $actory pre,
pro#rammin# process. .t is necessary to de$ine %hat should be done i$ invalid bloc- is reached
durin# pro#rammin# , see 2.nvalid bloc- replacement scheme3 para#raph later.
Durin# the device li$etime (ac&uired invalid bloc-s). NAND $lash memory has a $inite li$etime and
%ill eventually %ear,out. /ince each bloc- is an independent unit, each bloc- can be erased and
repro#rammed %ithout a$$ectin# the li$etime o$ the other bloc-s. Bach #ood bloc- can be typically
repro#rammed $or 100 000 up to 1 000 000 times be$ore the end o$ li$e. 'here$ore bloc-s should be
mar-ed as invalid and no lon#er accessed i$ there is either a bloc- erase or a pa#e pro#ram $ailure.
Ac&uired invalid bloc-s are usually labelled and treated in the same %ay as the inherent invalid
bloc-s. 'here are various techni&ues ho% to minimi;e the bloc- %ear,out. 'hey must be ta-en into
account $or tar#et device system desi#n, but typically are out o$ concern durin# the $actory pre,
pro#rammin#.
ersion 1.00!02.2009 "a#e = o$ 20
NAND Flash Memories Application Note
Seven elements of NAND flash factory pre-programming scheme
NAND $lash $actory pre,pro#rammin# scheme consists o$ seven basic elements that need to be speci$ied
to cover all NAND $lash issues. 'hese are<
"artitionin# scheme
.nvalid bloc-s replacement scheme
Dynamic meta,data scheme
/pare area arran#ement scheme
Brror control and correction (B99) scheme
Anused bloc-s $ormattin# scheme
.nput data $ile scheme
/ee $ollo%in# pa#es $or details on individual schemes.
ersion 1.00!02.2009 "a#e > o$ 20
NAND Flash Memories Application Note
Partitioning scheme
'ypically, there are various -inds o$ data pro#rammed into NAND $lash memory device. 'hese various
data types may need to be processed usin# di$$erent approaches. Also, each data type may need to start at e4actly
speci$ied location.
Fi#ure : sho%s an e4ample o$ simple device partitionin# scheme. 'here are $our partitions de$ined in
device $or bootstrap, bootloader, operatin# system and $ile system in this e4ample.
*ne can see that some partitions contain paddin# area. "addin# area represents the 2reserve3 meant $or
invalid bloc- treatment or $or $uture use. B.#. i$ bootloader code needs 7 bloc-s, it is #ood practice to allo% 1 or 2
other bloc-s $or invalid bloc-s replacement.
"addin# area can also cover %hole partition, i$ some special pre,$ormattin# o$ bloc-s that are ready $or
use is necessary. For more in$ormation on paddin# area $ormattin# see 2Anused bloc-s $ormattin# scheme3
para#raph later.
ersion 1.00!02.2009 "a#e C o$ 20
Figure %. NAND flash memory par"i"ioning e#ample
NAND Flash Memories Application Note
"lease, note the bri#ht,blue coloured areas bet%een the partitions. 'hey represent areas that are not
intended $or use, so,called 2#aps3. 'here is no meanin#$ul reason to %aste the memory capacity and le$t the #aps
bet%een the partitions. 0o%ever, there can be some other partitions de$ined, out o$ scope durin# $actory pre,
pro#rammin# (%ill be pro#rammed later, e.#. a$ter tar#et device burnin#,in).
'he opposite situation , partitions overlap , is $orbidden.
'o de$ine the partition, the $ollo%in# values must be speci$ied<
"artition start , physical address (bloc- number) %here partition starts.
"artition end , physical address (bloc- number) %here partition must stop. 'ypically, an error is
reported i$ it is not possible to pro#ram all re&uired data to area bet%een partition start and partition
end.
"artition si;e , the si;e (in bytes or bloc-s) o$ partition data. Area behind the partition si;e until the
partition end comprises the paddin# area. .$ there is none invalid bloc- in partition, only the area
correspondin# to partition si;e %ill be used. 8ut in case o$ invalid bloc-s occurrence, bloc-s $rom
paddin# area %ill be used to replace those invalid ones.
ersion 1.00!02.2009 "a#e 6 o$ 20
Figure &. 'ar"i"ione( (evice versus buffer mapping
NAND Flash Memories Application Note
Fi#ure 7 sho%s an e4ample o$ device versus bu$$er mappin#. 'he scheme %ith t%o partitions is used.
'here is one invalid bloc- in data area $or "artition 1 and another one in paddin# area $or "artition 2.
*ne can see that input data $ile must cover also paddin# areas. 'ypically, these areas are le$t blan-. .$
any $ormattin# o$ paddin# bloc-s is re&uired, there are t%o possibilities<
all necessary $ormattin# data can be included in input data $ile (simpli$ies al#orithm implementation
so it can be done $aster), or
special $ormattin# must be speci$ied in Anused bloc-s $ormattin# scheme (input $ile still must
contain blan- bytes $or that areas).
'here are t%o aspects that must been ta-en into account %hen de$inin# partitionin# scheme<
0o% many data types %ith di$$erent processin# re&uirements %ill be pro#rammedD
0o% many data areas need to start at e4act addressD
A$ter the number o$ partitions is determined, also the start, end and si;e o$ each partition must be
speci$ied. Also, all other schemes must be speci$ied $or each one partition. 0o%ever, very o$ten all partitions use
the same scheme.
ersion 1.00!02.2009 "a#e 9 o$ 20
NAND Flash Memories Application Note
Invalid blocks replacement scheme
.nvalid bloc-s replacement scheme speci$ies ho% to proceed i$ invalid bloc- is reached durin#
pro#rammin#. .t is o$ten so,called .nvalid bloc-s mana#ement scheme.
'hree #enerally used schemes are discussed in $ollo%in# para#raphs.
gnore invalid bloc!s
'his scheme is used mainly in older systems. Asin# .#nore invalid bloc-s scheme, invalid bloc-s are
i#nored (treated as bein# valid). .n conse&uence, respective data are lost. .t is necessary to bac-,up system critical
data , but this raises demand on additional memory capacity.
As the scheme is rather inconvenient in comple4 system, it is used very rarely. 0o%ever, it can be still
used $or stora#e o$ the unimportant data, i$ eventual data loss can be $or#iven.
ersion 1.00!02.2009 "a#e 10 o$ 20
Figure ). *gnore invali( bloc+s scheme
NAND Flash Memories Application Note
S!ip invalid bloc!s
'his is the most commonly used invalid bloc-s replacement scheme. .$ invalid bloc- is reached durin#
pro#rammin#, it is s-ipped (le$t on its o%n) and relevant data are pro#rammed into ne4t valid bloc-. Data $or all
other bloc-s are shi$ted by one bloc-, until other invalid bloc- is reached. 'his %ill be s-ipped a#ain, relevant data
%ill be pro#rammed into ne4t valid bloc-, so data %ill be shi$ted by t%o bloc-s $rom no%... and so on a#ain. .n this
%ay, data end %ill be shi$ted by the number o$ invalid bloc-s reached durin# the pro#rammin# ($rom that reason
there is paddin# area used i$ partitionin#).
ersion 1.00!02.2009 "a#e 11 o$ 20
Figure ,. S+ip invali( bloc+s scheme
NAND Flash Memories Application Note
"eserved bloc!s area
+eserved bloc-s area scheme divides the memory device into three areas (see Fi#ure C)<
Aser Area (so,called Data Area)
+eservoir (so,called +edirection Area)
+edirection 'able Area (so,called .n$o Area)
ersion 1.00!02.2009 "a#e 12 o$ 20
Figure -. Reserve( bloc+s area scheme
NAND Flash Memories Application Note
"rimarily, the user area is used $or data pro#rammin#. .$ invalid bloc- is $ound, the al#orithm searches the
reservoir $or suitable valid bloc- and uses it $or replacement. 'hen, the pro#rammin# process continues $rom ne4t
bloc- in user area.
A$ter the pro#rammin# is $inished, the in$ormation about redirected pairs is compiled and pro#rammed
into redirection table area.
Ehat is necessary to speci$y +eserved bloc-s area scheme completely<
Aser Area start and end, eventually start and si;e
+eservoir start and end, eventually start and si;e
'he %ay ho% the bloc-s are pic-ed,up $rom reservoir (e.#. $rom start to end or $rom end to start)
'he number o$ redirection table copies
+edirection 'able Area start and end, eventually start and si;e (there may be also several areas
reserved $or redirection table , e.#. bloc- F0000 $or redirection table and the last device bloc- $or
table bac-up copy)
'he %ay ho% to select the bloc- $or redirection table copies pro#rammin# ($rom start, $rom end,
etc...)
+edirection table $ormattin# (headers, chec-sums, redirected pairs $ormattin#, etc.)
ersion 1.00!02.2009 "a#e 1: o$ 20
NAND Flash Memories Application Note
Dynamic meta-data scheme
All data, that MA/' be prepared on,the,$ly durin# the $actory pre,pro#rammin# procedure are called
2dynamic meta,data3. 'hey MA/' be prepared on,the,$ly, because , o$ their nature , it is not possible to build
involved $ields, tables, etc. at data preparation sta#e. 'ypically, these are<
serial numbers
MA9 addresses
invalid bloc-s lists (based on invalid bloc-s occurrence)
lists o$ bloc-s $ree $or use (valid yet not used bloc-s)
mappin# tables (based on lo#ical to physical bloc- numbers mappin# , see redirection table in
previous para#raph)
$ile system headers
and similar
Ehat is necessary to speci$y Dynamic meta,data scheme completely<
e4act locations and si;es o$ all dynamic meta,data $ields, tables, etc.
e4act speci$ication ho% the meta,data should be loaded (serial numbers, MA9 addresses) or
compiled (bloc-s lists and similar)
ersion 1.00!02.2009 "a#e 17 o$ 20
NAND Flash Memories Application Note
Spare area arrangement scheme
/pare area carries various -inds o$ system,level in$ormation, such as lo#ical bloc- ! sector numbers,
operatin# system loo-,up data, bloc- validity label, bloc- usa#e ! $ree label, B99 chec-sums, etc.
.$ your system uses spare area only $or stora#e o$ bloc- validity in$ormation in the same manner as the
memory devices manu$acturer1s speci$ication says, the spare area can be considered bein# 2not used3. .n such a
case, don1t $or#et to speci$y that you are not usin# the spare area.
.n all other cases the spare area is used.
/pare area data $or static data areas can o$ten be pre,computed and included into input data $ile. .t is
recommended to do so, as this %ay simpli$ies al#orithm implementation and veri$ication ($aster implementation
time), reduces "9 processor load ($aster pro#rammin# time) and simpli$ies system chan#es (e.#. i$ you %ill decide
to chan#e used B99 al#orithm, no chan#e in device support %ill be re&uired). .$, despite o$ all above mentioned
advanta#es, you decide to let the pro#rammer compute the spare area data on,the,$ly, don1t $or#et to speci$y the
$ollo%in#<
each spare area byte e4act content assi#n
the computational al#orithm $or each $ield o$ spare area (lo#ical sector ! bloc- numbers, B99
chec-sums, etc.)
/pare area data $or dynamic data areas must be, similarly the dynamic areas itsel$, computed on,the,$ly
durin# the $actory pre,pro#rammin# process. .n such a case it is necessary to proceed li-e i$ spare area data $or
static data are computed on,the,$ly, see previous case.
Ehat is necessary to speci$y /pare area arran#ement scheme completely<
.s spare area usedD
.$ yes, does input data $ile contain also relevant data $or spare areaD
.$ not, %hat is spare area bytes assi#nmentD 0o% to compute their valuesD
.$ device contains dynamic data areas , do these areas use spare areaD
.$ yes, %hat is spare area bytes assi#nmentD 0o% to compute their valuesD
ersion 1.00!02.2009 "a#e 1= o$ 20
NAND Flash Memories Application Note
Error control and correction scheme
arious error recovery mechanisms are used to minimi;e device $ailure rate durin# the read operation.
/in#le,bit errors (so,called $lip,$lops) in NAND $lash technolo#y occur naturally. All NAND $lash memories
manu$acturers recommend to use an error control and correction (B99) al#orithms to e4tend the memory devices
li$etime. 'ypically, 2 bits detectin# ! 1 bit correctin# al#orithm is recommended $or sin#le,level cell devices. 'he
situation is rather %orse %ithin multi,level cell device , typically 7 up to 12 bits correctin# al#orithms are re&uired.
B99 control sums are typically stored in spare area. 'heir byte position assi#nment should be speci$ied in
/pare area arran#ement scheme. Also, their includin# into input data $ile is recommended, similarly to other spare
area data.
.$ B99 control sums should be computed on,the,$ly, it is necessary to e4act speci$y the al#orithm ho% to
compute the sums. 'he simplest %ay is to attach the B99 al#orithm source code %ritten in 9!9?? or "ascal
pro#rammin# lan#ua#e.
ersion 1.00!02.2009 "a#e 1> o$ 20
NAND Flash Memories Application Note
Unused blocks formatting scheme
/ometimes, it is necessary to pre,$ormat also the bloc-s that are not used (e.#. some operatin# system
speci$ic data in spare area). 'here can be t%o -inds o$ such bloc-s<
Padding bloc!s
'he $ormattin# data can be included in input data $ile. Asin# this %ay, ho%ever, the bloc-s %ill be not
considered unused by pro#rammer. .t is necessary to speci$y that omittin# o$ e4cessive bloc-s that cannot be
pro#rammed into speci$ied user data area (partition) is allo%ed.
*ther %ay is to speci$y the pre,$ormattin# scheme and le$t correspondin# area in input data $ile blan-.
A$ter pro#rammin# the area correspondin# to partition si;e (see "artitionin# scheme para#raph) the remainin#
bloc-s until the partition end %ill be processed usin# the speci$ied scheme.
nvalid bloc!s
+emember, that inherent (device ori#inal) invalid bloc-s are present already at time o$ memory device
shipment. 'hey are labelled usin# some labellin# scheme speci$ied by device manu$acturer. .t is hi#hly
recommended to adhere to this scheme and don1t violate it. Also, it is recommended to use the same scheme $or
ac&uired (raised on use) invalid bloc-s.
/ometimes, it may be necessary to use some speci$ic $eatures $or ac&uired invalid bloc-s labellin#. B.#. a
value o$ 040F may be used instead o$ common 0400. *r all locations inside o$ ac&uired invalid bloc-s may be
pro#rammed to 0400.
/ince ne% invalid bloc-s can arise also durin# $actory pre,pro#rammin# operation, it is necessary to
speci$y and implement invalid bloc-s (o$ both types) labellin# scheme already $or device pre,pro#rammin# support.
.t may be speci$ied as a part o$ .nvalid bloc-s replacement scheme.
ersion 1.00!02.2009 "a#e 1C o$ 20
NAND Flash Memories Application Note
Input data file scheme
.deally, input data $ile should contain a 2mirror3 o$ device content. As NAND $lash memory devices
capacities are o$ten really hu#e (several #i#abytes), such input data $iles became rather uncom$ortable. 'here$ore,
there are various techni&ues used ho% to 2pac-3 unused (blan-) areas. .$ any such techni&ue is used, the e4act
speci$ication must be provided.
/ometimes, there can be some sa$ety $eatures used to disable the usa#e o$ incorrect $ile. B.#. the $ile
compiled $or pre,pro#rammin# al#orithm o$ revision 1 cannot be used in combination %ith pre,pro#rammin#
al#orithm o$ revision 2. All such $eatures must also be e4actly speci$ied.
ersion 1.00!02.2009 "a#e 16 o$ 20
NAND Flash Memories Application Note
#onclusion
'here isn1t any #eneral template available so that %e mi#ht simply allo% you to $ill,in and sent to our
technical support department. "lease, use this application note as the #uideline and build your o%n speci$ication in
easy readable $orm. Ee can accept the speci$ications in D*9, G@/, ""', *D', *D', *D", "DF, ra% te4t and
compatible $ormats.
"lease, %rite your speci$ication usin# Bn#lish lan#ua#e. Avoid usin# national $onts, as they may became
not,readable on our side.
.$ you have any doubts in terminolo#y, try to e4plain the tas- in your o%n %ords. Hou can use also some
-ind o$ easy understandable pro#rammin# &uasi,lan#ua#e (9,li-e). Ee %ill contact you an discuss eventual
problems.
Don1t $or#et to attach e4act al#orithms $or all on,the,$ly computational tas-s, such as B99 and similar.
'he most use$ul $orm is the al#orithm implementation source code in 9!9?? or "ascal pro#rammin# lan#ua#e (may
be, the part o$ the pro5ect code $or your tar#et application memory controller , this is the best %ay to ensure the
consistence %ith your pro5ect).
"lease, attach also sample input data $ile $or implementation veri$ication purposes on our side.
"lease, assume, that %e may as- you $or sample memory devices (1 to 7 units). 'hey can be sent bac-
to you a$ter success$ul implementation, ho%ever, it is recommended to -eep at least one sample on our side $or
possible post,release support in case o$ any problems or modi$ications.
Do not hesitate to contact our technical support department in any doubts, even durin# the preparation o$
the scheme. Hou can use our Al#orithms *n +e&uest service available $rom our %eb,site<
http<!!%%%.elnec.com!support!al#or,service!.
ersion 1.00!02.2009 "a#e 19 o$ 20
NAND Flash Memories Application Note
$ersion history
ersion 1.0 I February 2009
I initial release
ersion 1.00!02.2009 "a#e 20 o$ 20