本帖最后由 dffzh 于 2025-4-22 09:05 编辑
#申请原创#
@21小跑堂
前段时间有个EtherCAT从站模块在客户现场出现偶发性问题，后面研发搭建环境进行了复现和分析测试，整个过程可谓是跌宕起伏，让我刻骨铭心......
下面就是整个过程，与大家分享一下，即使未从事相关行业的读者也可以阅读，咱们只取方法，希望可以让大家在解决Bug的道路上尽量少走弯路，一步到位！
一、问题描述
使用PLC主机扫描模块时，会偶现扫描失败，主机软件会报错； 偶发性Bug，需要反复测试才有可能会出现一次； 查看软件报错故障码，会显示：
二、软件层面分析 使用主机软件+主机+多个模块进行测试，并使用wireshark工具进行抓包分析；复现后，进行抓包分析，发现异常的模块会上报一个EtherCAT协议栈的中止码Abort code，为0x06020000，如下图所示：
此后，主站便不再对该模块下发FMMU，SM及状态机切换配置，从而导致主站扫描从站模块失败。从EtherCAT协议栈里寻找到中止代码 Abort code：0x06020000，表示对象并不存在：
该中止码在以下地方被调用：即当从站收到的对象字典索引不在已定义的对象字典里的时候，协议栈会上报该中止码；
0x08为中止码的索引，如下所示：
那到底收到的index值是多少呢？ 使用Keil进行软件仿真，重复测试出现报错后，查看报错时的index值，如下：
为什么这里会是这个值？ 是主站发错了？还是模块收错了？在报文里通过关键字 ecat.adp==0x3f6&&ecat_mailbox.coe.sdoidx==0xC010 搜索后发现主站并未下发该索引值：
0x8010等其他索引值是正常下发的：
至此，基本上就可以判断是从站模块出现问题了。 继续往上一层测试和分析：测试又出现，如下： 即每次出现的值可能会不一样；其中psWriteMbx即为直接从ESC寄存器读回的数据，已经为异常，说明协议栈本身没问题；
以上接口基本上就是最底层的通过SPI读取数据的接口了； 至此，可以猜想难道是SPI读写数据错误了？问题可能出现在SPI读写这块，设置变量，仿真分析，复现后如下：
即SPI读写数据出现了错误；将SPI读写接口由寄存器操作改为HAL库函数操作，也会出现异常；难道是SPI速率太快了？将SPI速率由当前的10MHz改成5MHz进行测试：从下午1:30测试到5:00，未复现异常。 然后就是上示波器进行波形测试和分析： 使用示波器测试了10MHz速率和5MHz速率时，SPI的CLK时钟波形图如下：
三、硬件层面分析
ESC芯片和MCU的SPI通信的通信速率10MHz 偏高，造成偶发性的数据接收错误；将通信速率改成5MHz后复测，未出现异常。但是之前设计时我们是需要支持10MHz的，但为什么现在出现问题呢？找到硬件原来的测试报告，看看这块的测试数据：
居然发现 测试报告10MHz 波形与实际测试波形不一致；惊呆了；查看原理图，滤波电容使用的是62pf：
然后查看BOM组件清单，里面居然是330pf：
对于RC滤波来说，电容越大，其截止频率越小，计算结果如下： 即实际生产时模块上的滤波电容使用了330pf，截止频率实际在9MHz多，小于10MHz，进而影响数据通信。 最后硬件反查，得到的结论是：滤波电容是在升级到V2.2版本的时候修改的，但BOM漏修改了！！！！ 中间可能参与别的项目事情或者该项目有其他停滞的原因，时间太久导致遗漏了此处更新。为了进一步验证，对比测试了62pf和330pf的SPI总线的CLK时钟信号波形，如下图：330pf电容，10MHz时钟信号波形： 62pf电容，10MHz时钟信号波形： 验证结果OK，从波形上看为BOM电容330pf参数偏大与原理图62pf不一致导致。
四、结论
1、嵌入式软件是离不开硬件的软件，所以以后咱还是得多学硬件知识，才能在解决Bug的漫长道路上少走弯路，提高效率；2、产品的任何问题，即使是偶发性或者出现概率低的Bug，咱也不能忽视，曾经有位前辈说过：随着产品生产量的增多，出现一次的Bug，以后肯定还会出现，我们必须严肃对待所有Bug！ 3、对于偶发性Bug，起初无法定位为软件问题还是硬件问题或其他问题的时候，可以先尽量从软件层面去做减法，排除能想到的所有可能性，逐层深入，也许就会柳暗花明！
以上是作者实际遇到的产品Bug，虽然最终原因比较简单，但其实是比较典型的，所以分享出来！
如果大家有什么刻骨铭心的Bug或者比较“恐怖”的Bug疑难杂症，欢迎来贴分享！ | 
楼主
标题置顶
标题高亮
我们开会常讲，在实验室遇见的问题不管后续有没有复现，到了现场问题只会被无限放大，所以不能放过任何的细节。
能把偶发性Bug解决，实属不易
