[SPI通讯] 没有被SPI调试搞痛过吗

前言

没有被SPI调试搞痛过，敢说自己调试过SPI通讯吗？分享一次调试SPI的经历，其中遇到的困难和问题，以及应对问题的方法，可能对读者有一定的参考意义。当然读完后，没有发现有价值的东西，还请求继续读下一篇........

硬件环境

一块MCU走SPI连接到iMx6solox上，imx6solox上跑的是嵌入式linux系统，MCU端SPI作主，imx6solox端SPI做从。

软件调试

1、开始阶段的软件验证硬件，比较顺利。
使用一块USB转SPI小板作为SPI主（小板USB插入PC，在PC上有上位机软件控制），imx6solox的SPI为从，mode为0，速率1000kBPS，每字8位。
在imx6solox的linux端，使用spidev_test（/tool/spi/spidev_test.c）作为软件调试工具，比较顺利调试通过，当然仅仅是小数据量的单次收发。

2、在mcu通过connector插入后，遇到困难。
真正的苦难开始于大数据量的传输调试，数据丢包，并且是随机丢包。

3、丢包的追踪和分析

3.1. SPI驱动的初始默认buf大小为512字节，相对我们的需求来说太小，修改到4K字节；
3.2. 在SPI驱动里发现SOC平台发开者遗留的一个修改注释：在每次transmit后，都会将底层SPI使用到的FIFO清空（这是为了处理另外一个SPI发送的issue，而做的临时解决方案），由于imx6端仅仅是从SPI上读数据，不做发包操作，所以暂时关闭这个workaround修改；
3.3. 根据SPI的buf的大小计算一次获取的数据量大小，保证（N * SPI主每次定长发包的SIZE）<= IMX6下SPI驱动buf大小；
3.4. 担心硬件有问题造成数据丢包，将SPI的mode修改到1，在时钟下降沿来获取数据。
期间和硬件同事使用示波器查看过SPI的波形，mode0时，看到的波形还不错，没有发现可疑问题，修改为mode1，只是保险搞法；

经过以上修改，长时间测试，未发现随机丢包问题。由于项目周期压力过大，被丢包搞疼后，没有时间回头去找到ROOT原因。  

暂告一个段落

SPI数据传输，在不久的将来还降扩展到更大的传输速率上，那么当前的SPI设置和workaround的方案还将继续接受考验。
以此文档记录下遇到的问题，作为以后调试的依据。

当然，回忆每次调试SPI通讯的时候，困难来自于哪里？从自己的经历看，来自于以下几个方面。
1. 由于项目周期压力很大，多模块并行开发。
SPI的双工特性，作为SPI发送数据的一方，他们自己的代码也在开发中。而开发者都对自己的代码较为自信，并希望SPI接收方来帮助自己验证接收数据的完整性和有效果性；如果SPI本身就不稳定的话，在调试中带入的不确定性太大。

2. 以SPI主从模式看，想要搭建这样一个闭环的测试环境较麻烦
可以通过飞线的方式，搭建一个自发自收的SPI通路。但是在模拟数据发送的操作时，和真实的项目应用场景（MCU发送数据）还是有较大差异。自发自收不丢包，但是MCU->iMX6时，就随机丢包。

3. 硬件的不确定性
硬件的同事第一次基于imx6做这样的板子。早期在软件开发还没有完成的情况下，如何尽早的验证硬件的稳定性是一个课题。简单的数据传输正常可用，和在247的持续高速传输情况下的稳定性比，差距还是很大。编写类似的测试用例，还是很重要。

以上仅为个人项目总结