软件查Bug，最后是硬件BOM错了
本帖最后由 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疑难杂症，欢迎来贴分享！ 要从正规渠道买元件啊。 偶发性的问题还是比较难排除的，复现困难，分析困难，解决起来更困难。只有胆大心细花时间磨。 我们开会常讲，在实验室遇见的问题不管后续有没有复现，到了现场问题只会被无限放大，所以不能放过任何的细节。 gaoyang9992006 发表于 2025-4-21 20:42
要从正规渠道买元件啊。
倒不是元器件本身的质量问题，BOM错导致PCB贴错 qiangtech 发表于 2025-4-22 08:07
偶发性的问题还是比较难排除的，复现困难，分析困难，解决起来更困难。只有胆大心细花时间磨。 ...
确实，需要时间和精力才有可能解决 Chad1989 发表于 2025-4-22 08:33
我们开会常讲，在实验室遇见的问题不管后续有没有复现，到了现场问题只会被无限放大，所以不能放过 ...
对的，偶发性Bug也具有集群效应，产品到了一定的量后，出现的概率会越来越大，所以确实需要重视 硬件和软件踢皮球 这个查出来不容易，看着都糟心，楼主好样的 xionghaoyun 发表于 2025-4-22 09:21
硬件和软件踢皮球
那倒不会踢，遇到Bug，咱一般的操作风格是优先协同解决问题，相互踢皮球是最差的处理方式 飞思啦 发表于 2025-4-22 09:27
这个查出来不容易，看着都糟心，楼主好样的
{:lol:}能把偶发性Bug解决，实属不易 这个应该比较快就能确定
不过你们这个产品更改的流程看来有问题啊 示波器带宽有点窄啊, 换个4k左右的国产的吧。 1104有点老了。 从整个流程和文档来看，楼主公司还挺正规的 一位之前很牛的同事说过：“每一个NB的问题很可能都有一个很SB的原因”
这个流程偷懒造成的后果太严重了 解决了的问题原因其实大都很简单，难的费时间的是排查过程 dffzh 发表于 2025-4-22 10:31
能把偶发性Bug解决，实属不易
那挺好的 我打杂的 焊个板还要查硬件的问题 Siderlee 发表于 2025-4-22 10:37
这个应该比较快就能确定
不过你们这个产品更改的流程看来有问题啊
所以经验还是很重要{:handshake:} William1994 发表于 2025-4-22 11:44
示波器带宽有点窄啊, 换个4k左右的国产的吧。 1104有点老了。
确实，巧妇难为无米之炊 Wxy8030 发表于 2025-4-22 11:53
从整个流程和文档来看，楼主公司还挺正规的
BOM管控和审核制度还是需要继续完善
页:
[1]
2