Flash烧录SOP.docx
《Flash烧录SOP.docx》由会员分享,可在线阅读,更多相关《Flash烧录SOP.docx(11页珍藏版)》请在冰豆网上搜索。
![Flash烧录SOP.docx](https://file1.bdocx.com/fileroot1/2022-12/14/e71b6d9c-43c8-47c6-86bf-116e8d73e0ee/e71b6d9c-43c8-47c6-86bf-116e8d73e0ee1.gif)
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过多无效数据。