nor flash之擦除和写入

ReactNative: 将自定义的ReactNative组件制作成第三方库的详细流程(制作–>发布)

最近研究了下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”

容器环境的JVM内存设置最佳实践

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

第一步骤：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达到稳定状态。

本文链接：https://www.cnblogs.com/zqb-all/p/12207924.html

专注细节，回归本质，成败在微小之间