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

SPI调试实战

最新推荐文章于 2025-10-23 01:56:46 发布

原创

最新推荐文章于 2025-10-23 01:56:46 发布 · 2.5k 阅读

8 ·

CC 4.0 BY-SA版权

分享一次SPI通讯调试经历，解决大数据量传输中的随机丢包问题。通过调整SPI驱动缓冲区大小、关闭不必要的FIFO清空操作、调整数据包大小及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，只是保险搞法；

经过以上修改，长时间测试，未发现随机丢包问题。由于项目周期压力过大，被丢包