EsDA工控单板
EPC6450-AWI/EPC1107-LI/EPC3568系列工控板
MPC-ZC1迷你工控主板
Cortex®-A5,拖拽式开发,40pin扩展引脚
2.5寸工控单板
EPC-6Y2C-L网络控制器
Cortex®-A7,800MHz,8路串口,数字音频
IoT-6Y2C-L物联网关控制器
Cortex®-A7,800MHz,8路串口,支持蓝牙
EPC-6G2C-L网络控制器
Cortex®-A7,528MHz,8路串口,数字音频
IoT-6G2C-L物联网关控制器
Cortex®-A7,528MHz,8路串口,支持蓝牙
3.5寸工控单板
IoT7000A-LI物联网网关控制器
Cortex®-A7,双MiniPCIe接口支持无线模块扩展
IoT-9608I-L网络控制器
Cortex®-A8,800MHz,6种无线通讯方式
EPC-9600I-L工控主板
Cortex®-A8,800Mhz
IoT9000A-LI工控主板
Cortex®-A9,强劲编解码,专注多媒体
IoT9100A-LI工业IoT网络控制器Cortex®-A9,1GHz
SX-3568系列主板Cortex®-A55,双核心GPU
MD-3568LI工控板Cortex®-A55,双网口

十万次掉电测试是怎样炼成的?

少年,不得了了,出大事了!

“监测了一个月的数据,昨晚碰上意外断电,Flash盘里数据全没了!怎么办?”

“客户设备意外停电,来电后Flash盘里的程序都没了!怎么办?”

“系统掉电后,flash盘里目录全部变乱码了!怎么办?”

这些问题的罪魁祸首就是Flash文件系统不具备掉电保护特性。

数据安全日益重要,而文件系统却依然我行我素不管掉电过程中文件的死活,这怎么能忍!

致远不能忍!

不过光有一腔热血是远远不够的,解决问题还需进行全面细致的调研。Nand Flash在擦除和写入过程中发生掉电在实际应用中是极有可能发生的,那么在NandFlash擦除/写入时掉电会发生什么呢?为什么会造成如此恶劣的影响呢?下面我们来一一剖析。

以8位 SLC工艺的NandFlash写操作为例,掉电时写到怎样就是怎样。譬如写入0x01 0x02 0x03 0x04,写到0x03时断电,此时FLASH中有如下可能:

如果是MLC结构,同样写到0x3,那可能结果就是:

理想很美好,现实很骨感,写入0x03都能蹦出这么多种情况,实际应用中的突发掉电造成的结局就更千奇百怪了。那如果在文件系统中没有相应的预防措施会发生什么惨案呢?

WinCE内核中,文件系统版本主要包括 exFAT,FAT32,FAT16,这几个文件系统都不具备掉电保护功能。以FAT32文件系统为例,我们放慢镜头,仔细观察在Flash写操作过程中到底发生了什么。

图1 FAT32文件系统读取文件示意图

上图是FAT32文件系统读取文件示意图,簇是 FAT32 进行数据存储的最小单位,文件按照链式结构存储,FAT表项中存储了下一个簇号,文件系统根据FAT表项中存储的簇号获取下一个簇,直至文件读取完成。

现在我们向文件末尾添加一些数据,文件系统将会为文件分配新的簇,将FAT表项内容改写为新的簇号,将新添加的数据写入到下一簇号的数据区中,如此往复直至文件保存完成。

等等,说好的慢镜头呢? 我们是不是错过了什么?

镜头回到最开始,文件系统为文件分配新的簇,Flash对新分配的簇进行擦除操作,完成后写入新的数据内容。完成数据块的写入后,改写FAT表项内容为下一个簇号,如此往复直至文件全部保存完成。

那么问题来了,如果在写入数据块过程中发生断电,FAT表还没来得及更改,那是不是就意味着新修改的内容没有被保存?回答是肯定的,当然这也是最幸运情况之一了,因为并没有对原文件造成损坏,只是丢失了新添加的内容而已。

如果掉电恰好发生在操作FAT表、目录区呢,是不是有毛骨悚然的感觉?

WinCE默认的文件系统面对突发的掉电这么无助,难道我们只能袖手旁观?

不!

致远WinCE平台为了支持文件系统掉电保护功能,在文件系统中加入了TFAT特性,同时在驱动中添加掉电保护功能代码。为了验证TFAT特性和掉电保护功能代码的实用性,我们为WinCE平台量身打造了Flash掉电测试方案。

使用智能定时器控制被测设备电源,使用测试软件A监测文件系统状况,测试软件B进行数据拷贝操作,在拷贝过程中对设备随机断电,如此往复以模拟Flash写入时掉电,软件运行流程如下图所示。

图2 Flash掉电测试方案软件运行流程

宝剑锋从磨砺出,梅花香自苦寒来,经过一个月漫长的测试,测试次数约达10~12万次,若未出现失败信息则可为该平台发放Flash掉电测试通过许可证,自此仗剑走天涯!