Flash烧录SOP.docx
《Flash烧录SOP.docx》由会员分享，可在线阅读，更多相关《Flash烧录SOP.docx（11页珍藏版）》请在冰豆网上搜索。
Flash烧录SOP
Flash烧录SOP
修改记录
日期
版本
修改描述
修订者
2015.04.21
V1.0
初始版本
李胜良
本文主要针对工厂出现的批量烧录问题，以9832CV项目为例着重介绍了Flash基础知识、生产母片的制作过程、烧录器烧录过程；希望读者通过阅读本文能够对Flash的烧录有一个比较全面、大概的了解，便于后续项目的开发，减少不必要的重复工作。
一、Flash基础知识
1、Flash的存储原理
与DRAM以电容作为存储元件不同，闪存的存储单元为三端器件，与场效应管有相同的名称：
源极、漏极和栅极。
栅极与硅衬底之间有二氧化硅绝缘层，用来保护浮置栅极中的电荷不会泄漏。
采用这种结构，使得存储单元具有了电荷保持能力，就像是装进瓶子里的水，当你倒入水后，水位就一直保持在那里，直到你再次倒入或倒出，所以闪存掉电记忆能力。
与场效应管一样，闪存也是一种电压控制型器件。
NAND型Flash的擦和写操作均是基于隧道效应，电流穿过浮置栅极与硅基层之间的绝缘层，对浮置栅极进行充电（写数据）或放电（擦除数据）。
而NOR型Flash擦除数据仍是基于隧道效应（电流从浮置栅极到硅基层），但在写入数据时则是采用热电子注入方式（电流从浮置栅极到源极）。
2、NandFlash单元组织结构
如下所示，一般而言一片Flash由多个块（block）组成，一个块又分为若干页（page,一般是64页），一页由mainarea（2Kbytes）与OOBarea（128bytes）区域组成。
通俗的讲，我们将一片Flash类比为一个小区。
小区里的一栋房子好比Flash的一个块，房子的每一层好比Flash的一页，而每一层的一户人家就好比Flash的每一page的存储单元，另外每户人家都平均分配有8间房，类比Flash的一个字节存储单元，为了以示区分我们又将每一层某些区域分配给特殊用户居住，这就好比Flash的OOB区域。
块（block）是Flash的最小擦除单位，一般一个块大小为128K（0x20000）,也有256K及512K的，具体查看Flash的规格书；页（page）是NandFlash的写入操作的最小的单位,常见的nandflash页大小大都为为2KB（0x800），被称作bigpage；老的nandflash，页大小是256B，512B，这类的nandflash被称作smallpage。
现在市面上也有4KB页大小的Flash，具体也请规格书上查看的为准。
3、NandFlash的坏块和坏块标志
由于制造工艺的原因，NANDFlash在生产过程中可能会产生坏块，坏块在出厂前将会被标记。
对于坏块而言，存储的信息可能会丢失，不能正常使用。
另外在NANDFlash擦除或者编程过程中，出现操作失败后，表示该块不可以正常使用，也应标记为坏块。
所以在一般情况下，在操作NANDFlash之前，先要检查一下要操作的是否是坏块，以免坏块标记被破坏。
此外，为了保证存储信息的可靠性，从NANDFlash中读取的数据还可以引入ECC校验，ECC码一般存放在该页的spare区。
小页模式的NANDFlash（8bit）的坏块标志（BM）一般放在每个block第一页和第二页的第6个字节。
Spare区：
0
1
2
3
4
BM
6
7
8
9
10
11
12
13
14
15
小页模式的NANDFlash（16bit）的坏块标志（BM）一般放在每个block第一页和第二页的第1个字（双字节）。
Spare区：
BM
1
2
3
4
5
6
7
大页模式的NANDFlash（8bit）的坏块标志（BM）一般放在每个block第一页和第二页的第1个字节。
Spare区：
BM
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
大页模式的NANDFlash（16bit）的坏块标志（BM）一般放在每个block第一页和第二页的第1个字（双字节）。
Spare区：
BM
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
一般情况，坏块标志（BM）处为0xFF或者0xFFFF表示好块，非0xFF或者0xFFFF代表坏块。
4、nandflash的坏块管理
对badblock的管理有很多种方式,没有那一种方式被定义成标准方式。
例如:
一种通用的方式是跳过badblock,把数据写入到下一个好块中--这种方法被称为“SkipBlock”。
另外一种通用的方式叫做“ReservedBlockArea”,这种方法用已知好的block（块）来替代badblock,这些已知好的block（块）是预先保留设置的。
除此之外,其他应用需求对每个页内的数据进行ECC计算。
当badblock产生时,ECC校验被用来侦测badblock的出现并且做数据的修补。
ECC数据也会被写入备用区域。
4.1SkipBlockmethod（跳过坏块方式）
这个算法开始之前先读取存储器内的所有备用区域。
那些被标识成badblock的地址都被收集起来。
接下来,数据被连续的写入目标FLASH器件。
当目标地址与先前收集的badblock地址一致时,跳过坏块,数据被写到下一个好的块中。
然后继续保留badblock中备用区域的标识信息。
所以在程序导入执行之前,使用者的系统通过读取Sparearea（备用区域）的信息能建立一个badblock的地址列表。
4.2ReservedBlockAreamethod（保留块区域方式）
“ReservedBlockAreamethod”基于这样的法则,badblock在使用者的系统中能够被好block（块）所替代。
这种烧录算法首先决定将哪些block（块）用来做UBA（UserBlockArea）,这些block（块）将会被RBAmaptable记录,并且对其进行保留操作。
接下来算法读取Sparearea（备用区域）的信息然后建立一个map列表到RBA。
在RBA中唯一只有第一和第二个块被用来存储列表和对它进行备份。
这RBA中的map包含一些有了信息,如用RBA中的哪些保留块来代替badblock。
二、母片制作过程
以9832CV（broadcom7583平台）为例，母片的制作过程分如下几步：
1、通过Linux内核自带的dump命令，将Flash里的数据以MTD分区为单位拷贝到U盘。
一般我们dump出来的数据是带OOB,因而总的数据大小将有可能超出Flash空间大小这是因为通常我们所说的Flash容量是不计OOB区域大小的。
通常烧录厂家会询问母片数据是否带OOB,如母片数据不带OOB我们需要提供其计算OOB的算法或是源程序或工具。
以CV项目为例，dump命令可以通过命令参数控制输出数据是否带OOB数据，实际我们提供的数据是带OOB的。
且OOB数据区域的大小也是可以控制的，具体项大小由选用的具体Flash型号为准，并留有一定的余量。
2、根据分区的规划表将各MTD分区数据合成一个烧录镜像文件，并生成指导烧录器烧录用的分区表文件。
以CV为例合成工具设置如下：
工具各项参数说明如下：
TableFile：
烧录用分区表文件。
DataFile：
合成的镜像文件。
FileXX:
各分区的数据imge。
BlockStart:
规划给某一分区数据的起始block标号，以16进制表示，从0开始标号。
End:
规划给某一分区数据的终止block标号。
PageCnt/Block:
Flash每一个block包含的page数目。
ByteSize/Page：
某一页page包含的字节数。
以实际的数据为准，以CV项目为例，dump的数据为带OOB的，且OOB数据大小为128bytes,所以填写4096+128=4224.
分区表数据是分区烧录的主心骨，控制整个烧录的过程，分区表每行代表一个分区，以小端方式（littleendian）字节对齐,第一个四个字节（long）代表该分区的开始块地址，第二个四个字节（long）代表该分区的结束块地址，第三个四个字节（long）代表该分区实际要烧录（有效数据）的块大小，如下图所示：
三、Flash烧录过程
烧录过程由选用的烧录器不同而有略有差别，但都是大同小异，基本上是分为放置Flash至烧录座，装载数据、擦除、编程、校验这几步。
下面还是9832CV为例说明整个烧录过程。
1、选FLASH型号：
TC58NVG2S0HTA00（XYLC）；由于CV的烧录算法是根据inspur要求（只对mainarea数据进行大小端转换，而对OOBarea数据不进行大小端转换）定制的，当选定Flash型号后对应的烧录算法也就确定了，如下图所示CV所使用的算法版本号为：
3.2。
2、载入数据文件
3、载入分区表
4、分区表载入完成
5、特殊位设定:
BadBlockHandingMode栏目点选“Partition”，采用分区烧录的方式。
6、编程自动方式——>添加操作擦除-编程-校验——>自动
7、烧录过程（烧录成功）
四、案例分析
1、案例背景
9832CV试产时解决烧录问题后一切正常，然在5W订单批量生产时又出现了1%概率性烧录不良问题。
烧录提示校验出错、坏块超出容限。
2、原因分析
根据出错提示本能地认为可能是Flash出现批量不良坏块过多导致，通过用烧录器读取坏块标志发现坏块数量最多5个，与Flash供应商沟通了解到业内标准对一片正常的Flash允许的坏块总量为总block数量的2%，以TC58NVG2S0HTA00Flash为例，允许的坏块总量为（512M/256K）*2%=40个，而5远没有达到40个，所以可以判定不是Flash硬件问题。
通过分析坏块标号发现烧录不良的Flash坏块有一个共性，都集中在block标号为36~47（0x24~0x2F）这一区域。
查看这一分区数据对应为splash分区，该分区存放的是开机图片信息。
规划的大小为16个block大小。
从Flash空间规划来看足够放下一张图片，毕竟有16*256k=2M大小。
一般图片大小也就几百Kbytes,也即还有至少1M空间的冗余。
为什么还会提示坏块超限呢？
查看烧录用的分区表文件，发现实际要烧录该分区的block数量为0xC也即为12个。
而总的规划的大小为16个，假如不幸，刚好这一分区出现了4个以上的坏块，那就没有好块能装下这12个block大小的数据了，因而烧录器报错了。
用图表示如下：
问题又来了：
图片数据实际有这么大？
实际上数据没有这么大。
那为什么烧录器会认为要烧录12个block呢？
这还得从合成工具说起，烧录用的分区表文件是合成工具自动生成，从第二节我们知道了分区的某一行的第三个四个字节（long）代表该分区实际要烧录（有效数据）的块大小。
这个参数是根据什么生成的呢？
原来它根据该分区原始文件实际大小而生成的。
查看该分区的原始文件大小确实也是12个block大小，打开它发现其末尾全是0xFF这些数据。
至此终于明白，究其原因就在于合成前的文件过大，也即制作母片的第一步dump数据时，dump了该分区的很多无效数据。
3、解决方案
通过分析概率性烧录不良的原因在于坏块集中在某一分区，而刚好该分区的好坏余量不够。
对应在不改变现有分区规划的前提下，可以减少实际要烧录的数据大小或干脆不烧录该分区予以解决。
有以下两种实施方式：
1）直接修改烧录用分区文件，将实际要烧录（有效数据）的块大小这一参数减小或改为零相当于不烧录该分区。
然这需要准备评估该分区有效数据大小，避免烧录数据不全而导致烧录不启机。
2）Dump数据时不要dump过多无效数据。
升级会员 