Flash烧录SOP

Flash烧录SOP
本文主要针对工厂出现的批量烧录问题，以9832CV项目为例着重介绍了Flash基础知识、生产母片的制作过程、烧录器烧录过程；希望读者通过阅读本文能够对Flash的烧录有一个比较全面、大概的了解，便于后续项目的开发，减少不必要的重复工作。

一、Flash基础知识
1、Flash的存储原理
与DRAM以电容作为存储元件不同，闪存的存储单元为三端器件，与场效应管有相同的名称：源极、漏极和栅极。

栅极与硅衬底之间有二氧化硅绝缘层，用来保护浮置栅极中的电荷不会泄漏。

采用这种结构，使得存储单元具有了电荷保持能力，就像是装进瓶子里的水，当你倒入水后，水位就一直保持在那里，直到你再次倒入或倒出，所以闪存掉电记忆能力。

与场效应管一样，闪存也是一种电压控制型器件。

NAND型Flash的擦和写操作均是基于隧道效应，电流穿过浮置栅极与硅基层之间的绝缘层，对浮置栅极进行充电（写数据）或放电（擦除数据）。

而NOR型Flash擦除数据仍是基于隧道效应（电流从浮置栅极到硅基层），但在写入数据时则是采用热电子注入方式（电流从浮置栅极到源极）。

2、NandFlash单元组织结构
如下所示，一般而言一片Flash由多个块(block)组成，一个块又分为若干页(page,一般是64页），一页由main area（2K bytes）与OOB area（128 bytes）区域组成。

通俗的讲，我们将一片Flash类比为一个小区。

小区里的一栋房子好比Flash的一个块，房子的
每一层好比Flash的一页，而每一层的一户人家就好比Flash的每一page的存储单元，另外每户人家都平均分配有8间房，类比Flash的一个字节存储单元，为了以示区分我们又将每一层某些区域分配给特殊用户居住，这就好比Flash的OOB区域。

块（block）是Flash的最小擦除单位，一般一个块大小为128K(0x20000),也有256K 及512K的，具体查看Flash的规格书；页（page）是NandFlash的写入操作的最小的单位,常见的nand flash页大小大都为为2KB(0x800)，被称作big page；老的nand flash，页大小是256B，512B，这类的nand flash被称作small page。

现在市面上也有4KB页大小的Flash，具体也请规格书上查看的为准。

3、NandFlash的坏块和坏块标志
由于制造工艺的原因，NAND Flash 在生产过程中可能会产生坏块，坏块在出厂前将会被标记。

对于坏块而言，存储的信息可能会丢失，不能正常使用。

另外在NAND Flash擦除或者编程过程中，出现操作失败后，表示该块不可以正常使用，也应标记为坏块。

所以在一般情况下，在操作NAND Flash之前，先要检查一下要操作的是否是坏块，以免坏块标记被破坏。

此外，为了保证存储信息的可靠性，从NAND Flash中读取的数据还可以引入ECC校验，ECC码一般存放在该页的spare区。

小页模式的NAND Flash(8bit)的坏块标志(BM)一般放在每个block第一页和第二页的第6个字节。

第1个字(双字节)。

Spare区：
第1个字节。

Spare区：
第1个字(双字节)。

Spare区：
块。

4、nandflash的坏块管理
对bad block 的管理有很多种方式, 没有那一种方式被定义成标准方式。

例如: 一种通用的方式是跳过bad block , 把数据写入到下一个好块中--这种方法被称为“Skip Block”。

另外一种通用的方式叫做“Reserved Block Area”, 这种方法用已知好的block (块)来替代bad block, 这些已知好的block (块)是预先保留设置的。

除此之外, 其他应用需求对每个页内的数据进行ECC计算。

当bad block 产生时, ECC校验被用来侦测bad block 的出
现并且做数据的修补。

ECC数据也会被写入备用区域。

4.1Skip Block method（跳过坏块方式）
这个算法开始之前先读取存储器内的所有备用区域。

那些被标识成bad block 的地址
都被收集起来。

接下来, 数据被连续的写入目标FLASH器件。

当目标地址与先前收集的bad block 地址一致时, 跳过坏块, 数据被写到下一个好的块中。

然后继续保留bad block 中
备用区域的标识信息。

所以在程序导入执行之前, 使用者的系统通过读取Spare area（备
用区域）的信息能建立一个bad block 的地址列表。

4.2 Reserved Block Area method（保留块区域方式）
“Reserved Block Area method” 基于这样的法则, bad block 在使用者的系统中能够被好block (块)所替代。

这种烧录算法首先决定将哪些block (块)用来做UBA(User Block
Area), 这些block (块)将会被RBA map table记录, 并且对其进行保留操作。

接下来算法读取Spare area（备用区域）的信息然后建立一个map列表到RBA。

在RBA中唯一只有第一和第二个块被用来存储列表和对它进行备份。

这RBA中的map包含一些有了信息, 如用RBA 中的哪些保留块来代替bad block。

二、母片制作过程
以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为例合成工具设置如下：
工具各项参数说明如下：
Table File：烧录用分区表文件。

Data File：合成的镜像文件。

FileXX: 各分区的数据imge。

Block Start: 规划给某一分区数据的起始block标号，以16进制表示，从0开始标号。

End : 规划给某一分区数据的终止block标号。

PageCnt/Block: Flash每一个block包含的page数目。

ByteSize/Page：某一页page包含的字节数。

以实际的数据为准，以CV项目为例，dump的数据为带OOB的，且OOB数据大小为128bytes,所以填写4096+128=4224.
分区表数据是分区烧录的主心骨，控制整个烧录的过程，分区表每行代表一个分区，以小端方式(little endian)字节对齐,第一个四个字节(long)代表该分区的开始块地址，第二个四个字节(long)代表该分区的结束块地址，第三个四个字节(long)代表该分区实际要烧录(有效数据)的块大小，如下图所示：
三、Flash烧录过程
烧录过程由选用的烧录器不同而有略有差别，但都是大同小异，基本上是分为放置Flash 至烧录座，装载数据、擦除、编程、校验这几步。

下面还是9832CV为例说明整个烧录过程。

1、选FLASH型号：TC58NVG2S0HTA00 (XYLC)；由于CV的烧录算法是根据inspur要求（只对main area数据进行大小端转换，而对OOB area数据不进行大小端转换）定制的，当选定Flash型号后对应的烧录算法也就确定了，如下图所示CV所使用的算法版本号为：3.2 。

2、载入数据文件
3、载入分区表
4、分区表载入完成
5、特殊位设定:
Bad Block Handing Mode 栏目点选“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大小的数据了，因而烧录器报错了。

用图表示如下：
Date imge Device
问题又来了：图片数据实际有这么大？实际上数据没有这么大。

那为什么烧录器会认为要烧录12个block呢？这还得从合成工具说起，烧录用的分区表文件是合成工具自动生成，从第二节我们知道了分区的某一行的第三个四个字节(long)代表该分区实际要烧录(有效数据)的块大小。

这个参数是根据什么生成的呢？原来它根据该分区原始文件实际大小而生成的。

查看该分区的原始文件大小确实也是12个block大小，打开它发现其末尾全是0xFF 这些数据。

至此终于明白，究其原因就在于合成前的文件过大，也即制作母片的第一步dump 数据时，dump了该分区的很多无效数据。

3、解决方案
通过分析概率性烧录不良的原因在于坏块集中在某一分区，而刚好该分区的好坏余量不够。

对应在不改变现有分区规划的前提下，可以减少实际要烧录的数据大小或干脆不烧录该分区予以解决。

有以下两种实施方式：
1）直接修改烧录用分区文件，将实际要烧录(有效数据)的块大小这一参数减小或改为零相当于不烧录该分区。

然这需要准备评估该分区有效数据大小，避免烧录数据不全而导致烧录不启机。

2）Dump数据时不要dump过多无效数据。