nor flash之擦除和写入

最近研究了下nor flash的掉电问题，对nor的掉电有了更多的认识。总结分享以下

擦除从0变1，写入从1变0

nor flash的物理特性是，写入以前须要先进行擦除。擦除后数据为全0xFF，此时写入操做，其实是将数据从1改为0。
通常先擦后写，但实际上擦除后每一个位置是能够写入屡次的，只要每次写入都是让某些bit从1变0便可。
例如在擦除后数据为0xFF，此时写入0x0F,可读出0x0F，再写入0x01，可读出0x01，再写入0x00，可读出0x00。
而对于0x00，就没法再改写成任何值了，由于此时每一个bit都是0，想要改写就必须先擦除，让其恢复到0xFF，再进行写入改为目标值。

屡次写入的例子

在uboot中就有一个利用nor这个特性的例子。当使用了冗余env功能时，flash上会维护两份env，咱们记为envA和envB吧。
既然有两份env，那就须要一种方式来区分哪份env的数据更新。对此uboot支持几种策略，其中一种可适用于nor的策略FLAG_BOOLEAN，uboot会在env的头部结构中，使用了一个字节flags来表示其是否有效。
假设当前A有效，B无效，则A的flags为0x1，B的flags为0x0. 读取时能够据此判断哪份env为新的。
写入时，uboot会先在ram的buffer中构造好flags为1的新env数据，再对envB进行擦除和写入。写入后flash上两份env的flags就都是0x1了。接着uboot直接对A的flags的位置写入0x0，即将本来的0x1不经擦除，直接改写为0，这样就快速地达到将A标记为无效的目的了。

写入过程掉电

对于nor来讲，一次写入能够连续写256 bytes，那若是在中途发生了掉电，再次上电后读出来的数据会是什么样的呢？
这个问题咱们很容易获得两种猜想：
假设nor中存在一片buffer，集齐256 bytes后再一次性刷到颗粒中，那么中途掉电大几率就是彻底没有写入，由于数据还在buffer中。也有小几率是正在刷buffer到颗粒中掉电了，那么这个时候写入的数据应该是乱序的。
假设nor中没有维护buffer，每一个bytes的波形接收到以后就写入固化下来，那么中途掉电大几率就是部分写入，并且是顺序的，即前面的数据写入了，后面的数据仍然为0xFF。

实测实际状况为假设二所述。
当写入一笔数据时，nor就是按顺序写入的，掉电后的数据特征为前面部分数据是正确数据，后面部分数据是0xFF。先后的交界点并未对齐到256 bytes。

擦除过程当中掉电

从nor flash原厂了解到，erase操做其实在flash内部分红三个步骤：
1）pre-program all "00"；
2）erase；
3）post-program all "FF"

那么在擦除过程当中掉电，可能出现的数据特征就比较多了。

第一步骤：pre-program all "00"；
当收到擦除命令时，首先flash会对这4k写入全0数据，这个是按前后顺序串行写入的，就理解为一个正常的写入全0数据。
若是在这个过程当中掉电，那么观察到的数据会是，前半部分的数据为0x00，后半部分的数据为原始的数据。状况跟上面描述的写入过程掉电同样。

第二步骤：erase
所有写入0以后，就进行擦除，擦除是会将全部的0都变成0xFF，这个是4k的数据并行进行的，在这个过程当中掉电，能够看到全部的数据都介于0-0xFF之间，乱七八糟的数据，没有任何规律。

第三步骤：post-program all "FF"
这一步其实我没太理解，但从掉电后的数据特征看，有一种状态可能跟这一步没完成有关。
即4k的数据，处于不稳定的0xFF状态。不稳定的意思是，某次上电读出来为全0xFF，从新上电再读，可能就是夹杂着一些0xFD, 0xBF之类的数据。

总结

以上咱们观察了写入和擦除中途掉电的数据特征。
从写入过程掉电的特征看，写入过程掉电可能致使nor仅将部分数据写入的，致使头部数据存在但总体数据是不完整的，所以不能简单依赖头部结构的MAGIC值来断定数据是否有效，重要数据须要作完整性校验。
从擦除过程掉电的特征看，擦除过程掉电可能致使flash上存在杂乱数据，或者不稳定的全0xFF数据，所以对于全0xFF的数据，写入以前仍是要先作一次擦除让nor达到稳定状态。

本文连接：http://www.javashuo.com/article/p-uiuleccp-be.html