flash擦除等待时间太短引起的一场血案

       之前针对外部flash的操作，没有太多深入的研究和应用过，基本上就是SPI通讯接口也是现有的，无需再调试的，应用的时候直接调用相关的擦除、写入、和读取等操作的接口。最近遇到一个与外部flash相关的问题，搞了好多天才最终查出问题的根源。关于产品相关部分的排查工作，我这里就不便多说了。只针对flash芯片部分的排查过程和一些新得感悟说一下。

     首先一个问题，外部flash的通讯接口是否统一都是SPI接口，这个问题其实我也不是很确定，但是就我接触过的外部flash芯片通讯接口都是采用SPI接口，SPI通讯涉及到4个引脚，MOSI、MISO、clk、cs。 SPI通讯的几个引脚可以通过逻辑分析仪来监控捕获对应引脚的信号。捕获通讯信号是排查外部flash通讯是否正常的一个很好的方式，在我分析和解决该问题的时候起到重要的作用。使用逻辑分析对应的上位机软件时，接好对应的引脚之后选择对应的监控通道，并需要根据SPI接口几个引脚初始化IO引脚电平进行了解，可通过SPI接口初始化部分的代码查看。修改好上位机软件的相关配置之后就可以进行捕获信号了。

      什么样的问题比较难搞？必现的问题其实更好解决，反而是偶然事件发生的问题难于排查。因为去在了解问题的过程就是 一个很麻烦的事情。遇到问题首先的思路是复现问题，看一下是否有规律可循，然后进行分析和推论。基于分析和推论的结果，你还需要进行大量的测试进行验证你的分析。而验证的过程有时候是相当痛苦的，不仅需要做较多的测试，如果分析过程中不够严谨，有些漏洞，那么肯定导致相互矛盾的结论。   下面我就用实践来说明这个道理。首先说一下遇到的问题。使用外部flash存储单片的升级包的时候，发现有时候会升级升挂掉，通过确认是升级包的第一帧在flash读取出来0xff,开始没有注意第一帧是否都是全0xff,后面发发现第一帧并不是都是全0xff,后面一部分是有写入数据的。问题大致就是这样。

1、开始怀疑flash数据没有写入，通过在flash的写入接口加一些返回值发现，返回值没有问题，貌似第一帧数据是写入成功了。被这一结论误导了一段时间，错误的认为第一帧数据写入成功了，是在后面不知道什么时候被擦除或覆盖了。

2、后面就通过添加测试代码进行测试，发现升级包接收完成之后，又连续接收到了一些升级包，有可能被后来的升级包帧把第一帧给覆盖了。但是通过监控串口报文发现，不没有重复收到第一帧的升级包，所以该分析结论也并不能完全成了。

3、后来又通过添加代码进行测试，每次写入之后进行读取，如果读取的数据异常则打印出来，发现在接收到连续几帧升级包之后，读取出的第一帧数据已经变成全0xFF了，此时还以为是发了几帧之后，第一帧的数据才变化的。因为看接口返回值是正常的。

4、最开始因为该芯片是低功耗芯片，每次操作的时候都要先唤醒，因为是唤醒这地方除了问题，在没有唤醒的情况下，进行了写入操作，导致第一帧没有写入成功。但是后面通过在唤醒的地方加了一些打印信息，发现唤醒是们没有问题的，写入接口的返回值也是没有问题的，所以导致问题定位变得有些模糊。

5、后来没办法只能上装备了，通过逻辑分析去捕获SPi通讯接口的信号，确认写入的数据是否正确，还是说接收的升级包数据在串口接收之后，SPI写入之前出现异常了。通过多次的测试，捕获信号发现第一帧写入数据的信号是没有问题的，随后读取的数据却是全0xFF，所以基本可以确定，是第一帧数据在写flash的时候没有写入。

6、flash写入出现问题基本是可以确定了，进一步分析逻辑分析仪捕获的信号，对比其他正常写入的升级包数据帧发现第一帧写入操作之后，等待flash ready状态的时间是正常写入等待时间的好多倍。进一步分析认为有可能flash芯片擦除操作的时候没有完成，还没有进入ready状态，就开始执行写入操作了，导致第一帧数据写入失败。于是编写了猜测是代码，确认了出现异常写入的时候确实是flash芯片处于busy状态，没有切换到ready状态。

7、在深入了解问题的过程中，感受flash芯片手册的重要性是巨大的，如果能对手册进行深入的了解，也许问题的解决会容易一些。但是一般的芯片手册都是英文版的，想要去深入的了解芯片也不是那么容易的。需要结合问题的分析，去详细的阅读和理解手册里的内容。

 

后续会补充捕获信号的截图，，，

flash扇区擦除操作信号：

 

 

flash写入操作捕获信号：