全部学习汇总： GitHub - GreyZhang/g_FUSA: some learning notes about function safety. Inlcude both ISO26262 and IEC61508
接着之前的内容继续看，这次把MCU安全测试中的存储测试单独拿出来。这个功能相对来说独立一些，也是存储测试以及校验比较通用的一些技术方法。
首先是非易失性存储的测试，包括Flash以及EEPROM等都属于这一类测试。这一类的存储通常是不会轻易发生变化的，尤其是在运行的过程中一般是不变的。因此，测试的时候一般是通过对内容进行校验来进行测试。
首次运行的时候，可以先把相应的存储进行一次校验，校验和写入到Flash或者EEPROM中作为一个参考值。后续的检查只做校验不做写入，这样，如果存储内容发生了变化便可以通过跟存储的参考值比较发现。
校验的方法很多，比较常用的就是CRC校验，而这种校验方式不管是从纯软件的角度还是利用某些高级MCU带有的CRC计算模块来计算都是可以的。
除此之外，其他的校验方式以及标记的流程都是可以视情况进行按需定制的。
关于RAM的检查，其实是有两大类的。第一种是一次性的检查，第二种是周期性的检查。这里给出来的三种MARCH算法都是偏一次性检查的，而CHECKBOAR的模式则可以灵活用在动态周期性的检查上。
MARCH的检查基本上是通过对存储单元的读写判断来实施的，但是MARCH一般不会测试堆栈部分的存储，因为这部分在软件运行的过程中可能由于算法本身导致变化。但是，这里也给出了一个stack检查的接口，后面需要分析一下实现，感觉上应该不是纯粹的C语言算法可以做到的。
上面总结了一下MARCH C的基本的过程，基本上就是6步。这样的过程除了第一步骤和最后一步之外，基本都是对前面的写入进行读取测试，然后写入新的数值。这种方式可以检查存储卡死、升序写入问题、降序写入问题、转换错误以及耦合性错误。
这种算法是一种破坏性的算法，因为写入的是整个存储区，没有其他的存储或者寄存器可以作为原始数据的保存缓冲区。因此，实施通常来说是启动的时候检查一次。
这个跟MARCH C几乎一样，只是少了一个最后的检查步骤。因此，这个效率会高一些，但是似乎会少一点准确度。
MARCH B能够检查出来的问题跟MARCH C是有不同的，比如说关联耦合以及翻转耦合等。本质上来说，操作判断的方式都是测试不同的写入或者读取是否生效。但是背后的机理的确是不容易的，之前我看了一个存储检查分析的报告，感觉这样的序列的得出的确是有很大的研究基础才行。
这个检查也是破坏性的，因此还是用在开始或者结尾会比较好一些。