当MCU死机了，先把硬件抓过来~

正文

---

大家好，我是bug菌！

上一篇文章跟大家聊了一下软件开发中偶发性问题的处理办法，这些都是手段，看似不是很难，其实最重要还是对问题的敏感度，而这份敏感度来源于你对整个系统的理解和把握。

当你能够尽快的缩小问题代码的范围，在一定程度上就已经加快了解决问题的进度。在上一篇文章末尾bug菌提到MCU程序直接死了以后软件上也有力不从心的时候，这时候我觉得你应该把做硬件的哥们揪过来了。

做嵌入式软件的朋友们也不要太高估了自己，虽然大家可以把硬件秀起来，但是你拯救不了“无药可救”的硬件。不要一头扎到代码的调试中，而是更多的分析现场和一些可能性的问题，先排查一些更加常见且易查的硬件问题，此时此刻示波器得秀起来~

1

电源问题

对于电源问题引起的死机，在这么多年软件调试过程了至少有碰到过10次左右，特别是一些经验不是特别丰富的软件工程师们在开发的过程中很少去质疑硬件问题，所以一言不合就从嵌入式软件开始排查，同时也有许多硬件伙计觉得软件可以优化非常多的硬件问题。

所以嵌入式软件没有一定经验在调试硬件问题会比较难受，那么对于电源这块能量的核心，主要是电压、功率和稳定性等。大部分芯片都会有一个稳定运行的电压范围，过高或者过低都有可能导致运行异常，注意是可能，不是一定，甚至同一个型号，不同批次的芯片都有所差异~

所以功率不够，电压过低会导致芯片内外供电不够，使得相应模块、外设运行异常，最终程序死机、跑飞是经常发生的。特别是整个系统的功率需求并不是特别稳定，且电源的设计并没有太多的余量，当出现比如动作继电器等等功耗较大的动作时，其电源就有可能出现不稳定状态，最终影响到芯片运行。

当然如果你是购买的劣质或者参数虚标的电源，就要更多的去测试和监控一下电源的稳定程度了。

所以bug菌目前亲自开发的项目，在项目的设计评审初期，会要硬件多留一个MCU的AD采样电路用来实时采集供电电压等，软件内部做一些快速的电压保护或者故障侦测，以检测出大部分电源异常问题。

2

复位电路干扰

相比电源问题会少一些，不过也遇到过几次，大部分都是板子刚打样回来上电调试的时候，MCU直接不运行的情况，大多都是复位电路中的电阻或者电容贴错了，虚焊了等等；如果是采用复位芯片的大多估计供电不足，选型有问题等等。

不过有一次遇到是在PCB走线上，复位电路与功率部分挨得比较近导致MCU概率性复位，当然如果有使用外部看门狗的话就更需要排查一下了。

3

晶振失效或受干扰

晶振本身失效或者受干扰，一般MCU都会选择外部晶振，相比内部的会更加准确一些。

然而对于这个MCU的心脏也是有概率出问题的，之前有个项目采用定时测量时间，每次测量信号的误差都是忽大忽小，后来直接把捕获的信号用IO信号翻转出来与实际信号进行对比，发现并无差异，才定位到是计时这块的频率出了问题，最终定位外部晶振电路存在干扰，导致时钟频率发生变化，最终影响测量结果，如果干扰再大一些估计就跑飞宕机了。

对于当出现了一些死机或者计时不准的问题，不仅仅要看软件，也要从硬件晶振时钟这块进行排查，所以对于目前主流的一些MCU都会存在时钟频率输出的引脚，一方面是用来供外部进行内部时钟的监控，另外一个应用就是进行不同芯片之间时钟上的同步。

4

最后几小点

最后，静电问题说实在的在开发中真的是虚无缥缈的存在，曾经一个伙计徒手换芯片，10个芯片换上去，坏了一半，大概率是因为天气比较干燥，用手触碰了几下芯片，后来硬件人手准备一套装备~

同时在系统中与MCU没有隔离的IO口，通信等等都要做好保护，这些对外的接口会把静电、或者是浪涌电压等引入MCU内部，使得MCU内部逻辑混乱导致死机。

高速运行的MCU会受外界辐射等电磁干扰，做好一些屏蔽措施等。

基本上遇到的MCU死机或者复位暂时就总结这么多吧，以后再想到一些再写写~

最后

      觉得有所收获，记得点个赞哦~

      同时跟大家推荐一下我的视频号:“bug直播间”，后续应该会在直播间跟大家交流一些技术心得或者开发经验，长按二维码即可关注~

推荐专辑  点击蓝色字体即可跳转

☞  MCU进阶专辑 

☞  嵌入式C语言进阶专辑 

☞  “bug说”专辑 

☞ 专辑|Linux应用程序编程大全

☞ 专辑|学点网络知识

☞ 专辑|手撕C语言

☞ 专辑|手撕C++语言

☞ 专辑|经验分享

☞ 专辑|电能控制技术