最近研究了下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之擦除和写入

擦除过程中掉电

从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,后半部分的数据为原始的数据。情况跟上面描述的写入过程掉电一样。
【学习通代刷】,nor flash之擦除和写入

第二步骤:erase
全部写入0之后,就进行擦除,擦除是会将所有的0都变成0xFF,这个是4k的数据并行进行的,在这个过程中掉电,可以看到所有的数据都介于0-0xFF之间,乱七八糟的数据,没有任何规律。
【学习通代刷】,nor flash之擦除和写入

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

总结

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

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