本帖最后由 dffzh 于 2025-6-19 08:44 编辑
#申请原创#
@21小跑堂
“这个程序在旧板子上运行正常的，在新板子怎么不行？硬件上的修改点不会影响到软件呀，怎么回事？，我也是服了！” “我是参考MCU官方demo程序写的SPI从机驱动程序啊，数据接收怎么异常呢？神奇了！” “程序在我这里运行正常的呀，LED正常闪烁的，你那里的板子怎么不行？不应该啊！” …… …… 其实还有很多来自于软硬件工程师们的经典话语，都是对不该出问题而实际又出问题的一种信息反馈！ 其实在工作中，这是最常见的也是最正常的现象了。我们在程序调试时，肯定都会遇到很多问题，包括程序仿真时卡死在某一个地方，程序一直进HardFault中断，又或者是程序在新硬件板子上运行异常等等，有些问题出现的很诡异，有些问题让人匪夷所思，有些问题也可能是调试环境影响而并非程序本身问题；总之，就是一句话，怎么会出现这样的问题呢？ 今天作者就从实际经验出发，针对一些常见的程序调试问题，给大家支一些招，希望能够进一步提高朋友们的快速定位问题的能力和技巧，从而提高解决问题的效率。
常见问题1：仿真器和目标板连接不上，无法下载程序 在我们进行程序调试之前，当然要先搭建好硬件环境，其实仿真器和目标板连接异常问题是比较常见的，有时候还不容易解决，因为涉及的东西比较多。如果你遇到这个问题的话，一般可以尝试通过以下的一些方法去逐一排查：（以jlink仿真器和keil IDE为例说明） 去设备管理器中确认仿真器是否已正常工作，即是否已安装驱动；
使用万用表电阻档测量确认SWD的连接线是否已连接正常； SWD连接线不要太长； 使用万用表直流电压档测量确认目标板MCU供电电压正常； 确认IDE里面已配置正确的仿真器；
适当降低仿真器和目标板的通信速率；
咨询技术支持等确认仿真器固件版本是否支持当前目标MCU或者直接升级仿真器固件； 将仿真器连接到开发板或其他正常板子，确认是否连接正常； 确认MCU复位电路是否正常； 更换MCU芯片等等。
常见问题2：程序仿真运行后不知道跑哪里去了 有时候进入仿真点击全速运行后，程序没有按正常逻辑执行。 此时，你可以点击停止运行程序：
然后看程序当前停在哪里：
可以多操作几次，看程序是不是都停在同一个代码位置，那基本上就是程序卡死在这块代码了，可以尝试屏蔽掉这块代码，然后再试试。 或者你也可以在main初始化代码位置打个断点，然后单步执行程序，看程序执行到哪里的代码后就无法继续执行下去：
以下情况也可能会导致程序运行后不知道跑哪里去了问题： MCU系统时钟配置错误； printf函数重定向异常； 外设中断已使能，但没有使用中断向量表完成中断服务程序的编写； 程序运行的ROM起始地址配置错误，注意是否带bootloader程序； 程序里增加了某些死循环操作等等。 然后如果你使用的是Cortex-M核的MCU，还可以在Watch窗口里监控一下SCB寄存器，这些寄存器会监控和记录一些错误故障信息。
比如其中的HFSR（硬件故障状态寄存器）就会记录HardFault异常。
常见问题3：部分板子的软件功能出现问题 有时候也会遇到这种情况，生产了一批板子，可是其中部分板子的功能不正常，并且经过初步的软硬件分析后也没找到原因，我们可能会怀疑是不是这批MCU芯片批次有问题或者一致性不好导致的。其实吧，MCU芯片出问题的概率是非常低的，不到万不得已，不要轻易去质疑这个原因，大部分情况下，还是我们的软件或者硬件存在设计缺陷导致的。 举个实际例子，之前有个坛友发贴咨询了使用PIC芯片实现的低功耗产品，有部分产品的低功耗数据偏大，尝试了交叉测试和代码减法测试，起初都没找到原因；后来通过咨询FAE和自己认真比对进入低功耗之前的GPIO配置代码，终于是定位到原因了，还是代码配置问题。 这种问题确实比较恶心，不静下心来认真查找分析，是很难定位原因的。那遇到这种问题，我们应该怎么去做呢？ 自我怀疑： 一定要优先认为是自己的软件或者硬件设计缺陷导致的，实际上很多情况也是如此，芯片本身问题毕竟少数吧。 很多问题或者Bug的迷惑性很大，特别是偶发性问题，你以正常思维去分析和理解，肯定是觉得设计本身没问题的；但是往往到最后，的确是设计上存在的缺陷导致的。 波形测试： 如果是与外置芯片相关的问题，可以尝试测试一下MCU和芯片的通信时序波形，看波形是否存在失真问题，或者与芯片手册里的波形对比看是否存在临界信号的问题，是不是CLK波形上升沿或者下降沿时间太长或者太短等等。 这一点很重要，做嵌入式软硬件开发，遇到问题时一定要有“我来测试一下波形”的意识，波形测试能解决很多问题；优先用示波器，协议数据分析时，可以用逻辑分析仪。 也一定要学会“会看”芯片数据手册，怎样算“会看”，就需要自己去摸索了，这里就不详细阐述了。 更换芯片测试： 如果是与芯片相关的问题，最快最暴力的方式就是更换一颗肯定好的芯片测试一下，如果好了，那要么是原芯片坏了，要么是软硬件设计不太好把芯片的一致性问题暴露出来了。 这个时候就可以看看信号线上的一些滤波电容是不是太大了？对于级联应用，是不是PCB走线太长导致时序错位了。 代码减法测试： 通过逐渐屏蔽相关代码进行测试，看异常板子是否会恢复正常，如果恢复了，那可能就是代码设计存在缺陷，比如通信速度偏高，延时时间偏长和GPIO配置不合理等等。 交叉测试： 在正常板子和异常板子之间进行芯片交叉测试，也可以进一步定位问题原因。 这个方法也是常用的，也要学会。
常见问题4：偶发性Bug，怎么办？ 在软件开发中，随着代码量的增多，有时候会出现一些奇奇怪怪的Bug，对于必现（每次测试都会出现）的Bug，一般通过仿真+信息打印+单步调试等手段都可以得到解决；但对于偶现（偶尔测试会出现）的Bug，或者是出现概率低的Bug，有时候消耗了好多脑细胞，尝试了好多方法，最后都没找到根本原因。因此，对于这样的偶发性Bug，一般怎么去排查呢？ 大胆猜想，根据现象，理论分析： 因为出现异常问题的机会并不多，所以要根据出现的现象多思考一下哪些地方可能会导致出现这个Bug？如果是客户现场出现，那是不是干扰问题？是不是操作方式问题？如果是干扰问题，那是不是软件滤波没做好？是不是总线通信速度太快导致？如果是操作方式问题，是不是软件代码逻辑顺序导致的？一定要结合出现的Bug现象，能尽量理论推导出一些能够与代码沾上边的信息，由后往前逐层分析，这样才有可能解决。 作者之前写了一篇文章（https://bbs.21ic.com/icview-3448040-1-1.html）就是关于解决一个偶发性Bug的；有一位坛友发的一个帖子（https://bbs.21ic.com/icview-3444870-1-1.html），引发偶发性串口通信问题的根源应该就是全局变量没有加volatile关键字声明；还有一位坛友发的关于有些板子出现低功耗数据偏高的（https://bbs.21ic.com/icview-3453022-1-1.html），最后排查出来也是代码配置问题导致的；有兴趣的可以看下。 监控数据，尝试复现： 不管能不能复现Bug，我们肯定是需要搭建测试环境自己测试一定的次数。我们可以直接通过软件仿真和Debug的方式进行，同时可以在IDE里监控你认为可能造成Bug的相关变量和标志位等，运气好的时候，说不定可以复现和监控到异常数据，这样有利于解决偶发性Bug。 记住：一定不要嫌麻烦，有时候为了尝试复现一些比较严重的Bug，自测一星期都是存在的，一定要静下心来好好自测，实事求是，切勿浮躁。 复现不了，增加防护机制： 如果实在搞不定偶发性Bug，那在代码上也不能啥都不做！ 可以在自己认为可能造成偶发性Bug的代码位置加一些防御式代码，保证出错后不影响程序的正常执行； 如果没加看门狗，一定要加上软件看门狗； 如果有总线通信代码，可以在不影响通信实时性的前提下适当降低通信速率； 如果有一些比较复杂的宏定义，建议一定多用括号括起来； 对于使用了数组的代码，注意数组坐标是否存在越界风险； 如果使用了指针，避免存在野指针等； 了解一下volatile关键字在哪些代码场景下需要使用它； 局部变量一定不要忘记初始化； 对于带操作系统的代码，注意临界代码的资源占用，避免变量值混乱。
以上针对程序调试这块列举了几个常见的问题以及根据自身经验提供了一些供参考的排查方法和手段，希望对你们有用。 如果有坛友遇到比较棘手的程序问题，也可以直接找我，我们一起研究看下。 | 
楼主
标题置顶
标题高亮
分析使用keil软件开发时常见的几种问题，分析其内在原因和可能性的解决办法。
@21小跑堂 管理员，你好，求原创审核哦！