销售GG在工作群里：“弟兄们，快醒醒，咱现场的跑马灯不跑了。”

还在加班的程序猿：“已经查过了，程序没Bug。”

带娃玩的硬件攻城狮：“硬件没问题，这都是照官方Demo弄的。”

刷剧的测试MM小声嘀咕：“我可都是按用例测的，没出问题啊。”

还是攻城狮有主意：“要不叫FAE过来看看？”

“好好好”，意见终于统一了，FAE也该起床换衣服了......

作为21世纪的嵌入式攻城狮，谁还没见过MCU死机啊，作为一个二手的程序猿，也见过大大小小的事故现场，于是乎，经过半个多月的思想斗争，我最后做出了一个违背祖宗的决定，把祖传百年的秘法无偿的献给国家。

1. 现场讲故事

弟兄们终于盼来了FAE，拉上手，快坐下，咱们说说知心话：“是你芯片问题吧，快点认了哈，这才好给老板交代啊。”

FAE：“GG，这恐怕不好吧，咱先看是不是马累了，跑不动了，要休息啊。”

程序猿：“不会的，我一直给它喂狗的。”

FAE：“没关系，我们还是先坐下，从头捋一把，看看下面这张图，听我讲讲故事吧。”

2. 故事开始

MCU死机一定是有原因的，往往有的流于表面，有的隐藏很深，特别是那种偶发的故障，直让人掉头发，遇到这种情况，最担心的恐怕就是程序猿了，所以看一个程序猿的水平从脱帽开始，而死机的问题，需要从查找现象开始。下面的故事分享会按照图中的现象标号来讲述，我们先进入第一个故事：

1.1.1电源的故事

MCU上电就不能工作，肯定会先看电源，结果有两种：

1. 电源有问题：这种情况下，硬件攻城狮应该就冲上来了，检查硬件设计或生成问题，比如峰值电源超过设计Spec，原理图/PCB是否设计有问题，板子焊接是否正确。
2. 电源没问题：等等，电源没问题，怎么还能归出这个问题呢？当然有可能，你见过画PCB封装时把Top和Bottom层画反了的么？

1.1.2 晶体的故事

上了点年纪的攻城狮应该还记得，现在很火的一款MCU早年间(大概07,08年)刚推出的时候，大面积出现晶体不起振的问题，民间传说已经到了拍下桌子就停振的程度。实际测试发现只有少数的日系晶体能完美规避该问题，以至后来官方给出Application Note(AN2867)去讲解晶体的选型，以及该MCU推荐使用的晶体型号。

多年以后的今天，有些MCU已经支持检测到外部晶体失效后自动切换到内部时钟，并触发中断的功能。不少用户也在产品测试的过程中，加入短接晶体的测试来验证系统运行的可靠性。

1.1.3 硬件配置的故事

MCU为了实现灵活的功能，会提供一些Boot配置管脚，MCU在上电Boot过程中会采样这些管脚状态来进入不同的模式，正常启动后就可以用作普通IO，常见的有从内部Flash启动，SD卡启动，QSPI启动，或者进入ISP模式等。所以当Boot管脚配置出现错误时，MCU断然时无法正常启动的。

前不久就有过这样一次不同寻常的加班之旅：使用德系MCU的新板子做回来了，该系列MCU不是第一次用，这次只是做了些外设的改动，不牵扯最小系统的修改，但是，仿真器始终连不上板子，奇怪的是10块板子中，只有2块有该问题。硬件GG比较给力，一晚上就发现了问题：出问题的板子MCU配置管脚电平与默认配置不符，该芯片的配置管脚可以定义Debug口Pin的位置，由于错误的配置导致连接仿真器的Pin已经不具备Debug功能，而错误的电平是由于硬件设计时，MCU管脚可能不够用，故将配置管脚也连到FPGA上备用，恰巧出问题的板子FPGA烧的测试固件没有将未用到的管脚设置高阻。

有些时候，ROM确实是一只拦路虎，当你发现配置管脚都正确的时候，芯片居然还不能工作。故事是这样的，用户首次使用MCU，根据自己的需求按照参考设计裁剪了一部分电路，打板回来后发现，无法连接仿真器，硬件GG对比参考板测量了所有信号都满足要求，从芯片内部的DCDC输出也正常，说明芯片已经正常跑起来了，最后还是老马识途，反复Review原理图后，大神发现自己的板子裁掉了EVK的USB电路，由于是新做的板子，flash里没有可以跑起来的正常代码，ROM会进入串口下载模式，而进入该模式前，ROM已经关闭了JTAG接口，因为外部没有给USB供电，所以ROM对USB的初始化会失败而卡死在这里，而解决方案也很简单，只要给USB VDD供电即可。

这里还有个51单片机的故事，当年这个产品支持热插拔，背板通过RS485进行数据通讯，实际现场发现，新挂设备后，会有非常小的概率上报错误帧。经过仔细检查发现，该单片机默认上电会有短暂的ISP模式，该模式下如果总线上有数据能对上ISP协议，单片机就会发送数据，所以插拔过程中可能会出现错误的数据发送到RS485总线上形成冲突。解决方案是再生产烧写的时候配置2个bit位，让其上电后不进入ISP模式即可。

1.1.4 MCU上电的故事

有不少的MCU会在Datasheet中规定上电的时序的要求，如果设计不能满足该要求，有可能会出现上电无法工作的现象。有些MCU在这种情况下，可以通过外部复位的方式重新运行，这样可以通过添加外部看门狗来规避该问题，有些MCU外部Pin的复位也无法让它重新正常工作，只能重新上下电，那就必须通过电源设计来保证。

敲黑板啦，这张图并不是单单讲上电哦，还有掉电的过程，当板子突然掉电，从3.3V掉到1.xV后又重新恢复到3.3V，那也是有可能无法正常工作的，掉电必须到200mV以下再上电才会比较安全。

从图上也能看出，一般都是要求斜率尽可能的陡一些，上电快一些，当然也有一些芯片太快了也不行，具体还要看手册。有了这个参数可并不一定能满足哦，硬件设计时，攻城狮从成本考虑往往会选择不带使能的LDO，这种芯片基本前级有电压后级就输出，所以前级上电慢，输出就会比较缓。MCU一般标称最低工作电压1.8V，但实际在1.1V左右就开始POR了，代码可能低于1.8V就开始跑起来了，如果此时代码加大负载，比如开启PLL，而此时LDO的输出能力也有限，VDD就会掉一个个坑，后面就真的是一个坑了......

所以，使用带使能端的LDO可以让输入电压达到比较高的值后再打开输出，以保证后级输出的线性及斜率够快。

如果真掉到坑里会出现什么结果呢，送大家几个知识点：

1. MCU停机无法启动，这是大家都不愿意看到的
2. MCU偏偏能启动，还能工作，但是内部模块初始化不完全导致功能异常，最常见的是Memory
3. MCU能正常工作，这种产品往往都是有住持开过光的，售价应该不菲

硬件改不了，那有没有降低问题概率的软件workaround呢？能想到的就是软件上来就把看门狗，BOD/LVD都打开（有些芯片默认是关的），如果能设置阈值就调到合理值。

还有些电源域比较复杂的MCU，需要通过PSWITCH管脚来控制内部DCDC的输出，当主VDD出现瞬间掉电(假设200ms后恢复)，外部的复位电路会对POR进行复位，但是由于时间太短不足以上PSWITCH产生复位信号去复位内部的DCDC模块，最后会看到出现VDD回沟后，MCU的DCDC挂了，外部高速晶振也无法起振。简单粗暴的解决方案就是把POR的复位信号和PSWITCH接到一起。

下面还有个和上电有关的故事，但和时序无关。

有个应用，需要每次上电的时候从外部的SPI Flash中拷贝固件到MCU内部的Flash中运行，产品本身生成很多年了，突然有个现场发现好几个模块不能正常工作。取回板卡发现，MCU内部的一段Flash无法访问了。查手册发现，该芯片对内部Flash操作时，如果对相同地址进行多次编程但不擦写就会出现该sector无法访问的问题。出问题的模块是通过POE进行供电的，出问题的现场由于是临时供电，所以经常断电，每次上电都会进行编程操作，由于业务逻辑复杂存在这样的风险。安全一点的做法应该是加入检验机制，如果内部的Flash固件已经是最新的，则不需要反复烧写。毕竟内部的Flash也有擦写寿命的。

1.1.5~8 IO口的故事

MCU需要通过IO口来输入输出，所以它需要与外部连接。那它就有一些规范需要遵守，比如极限的电压、电流，静电等级

设计上要尽量避免IO口先上电的情况，图中芯片所讲的5V tolerant是指VDD > 1.8V的情况，如果实际情况 < 1.8V呢？厂家肯定是不保的啊。

硬件设计IO的时候，该做隔离就隔离，别为了省点小钱儿后面再大整改，有些用户发现产线上有个别芯片工作正常，但是功耗特别大，快到1A了，拆下来做IV测试发现个别管脚已经烧掉了，仔细一琢磨，这片子还是不错的，毕竟没给烧坏喽。

讲到IO就不得不提下热插拔，绝大多数的芯片都是不支持的，带电反复热插拔都会对芯片造成一定的损伤，如果确实无法避免，可以考虑长短针的方式让电源和GND先接触，就像USB那样。

1.2.1 初始化的故事

作为曾经的程序猿小白，能Ctrl C来的代码绝不会多看它一眼，直接就上板跑了。搞了很多的笑话，不同的硬件设计，用了同一份代码，有的跑飞了，有的直接就不能连仿真器了，更绝的还会烧MOS。总之，板子的初始化最好拉硬件攻城狮一起，细细的对一遍，或者做一个表格让硬件GG填好。

针对时钟初始化，不要使用while()这样的等待，如果长时间失败，有可能外部晶体电路有问题，可以切换到内部的FRO继续工作，如果需要也可以通过对外接口将晶体初始化失败上报。

1.2.2 硬件问题的软件事故

几年前遇到一个量产的项目，发现有1ps的板子无法正常工作，回退软件版本不能解决问题，由于是量产项目，没有预留仿真器接口，而且对外只有1个UART通讯接口，还无法正常通讯，单从板子上也看不出什么问题，只有1个LED灯上电后会亮起，通过查看原理图发现，默认LED是不会亮起了，应该是软件点的，或者MCU坏掉了。检查代码发现，软件会初始化包括串口和LED在内的外设，然后去外部EEPROM中读取配置信息，如果配置信息有特殊字符，则进入测试模式，而测试模式代码并未实现任何功能。最终发现，问题是测试人员通过上位机修改了EEPROM中的内容，让MCU进入了没有任何功能的测试模式。这个问题其实也可以通过ABA替换测试，发现问题跟着板子走，从而定位到root cause

1.2.3 BOD/LVD配置

之前已经见过这哥俩的重要性了，如果有阈值的配置，也需要结合自身板子的设计来，之前有遇到过用户把LVD设置到2.5V产生解复位，但板子的VDD供电才1.8V。

2.1.1 看门狗的故事

相信有一些攻城狮并不知道，看门狗正常喂也会给MCU咬死.

举例1. 德系品牌MCU内部的看门狗默认开启恒复位功能，芯片第二次产生看门狗复位后立即锁定芯片并将IO口保持，这个对PLC的应用还是蛮重要的，它可以避免因为软件出现问题后反复持续的复位而导致被控设备的误操作

举例2. 美系品牌MCU内部的看门狗，即使不开window模式，复位间隔依旧不能太快，必须大于20个bus clock，否则也会咬死。

看门狗使用时切记使用芯片内部专用的时钟，如果使用外部时钟或者总线时钟，一旦时钟挂了，看门狗一样无法把MCU拉回来。

2.1.2 MCU复位死机

MCU能复位就说明它不想死，但往往最终还是架不住挂掉的命运。所以，复位源往往就是死机的一个前兆，通过它我们就能分析到大致的死因，就好比老西医看片子，老中医看舌苔。这里我们再介绍一个类似老中医的硬件问题：EMC问题

经测试，由它导致的MCU复位可以获取到不同的复位源，包括电源复位，Reset Pin复位，看门狗复位。导致的死机也包括HardFault_Handler，BusFault_Handler, UsageFault_Handler等等。

考虑到产品的稳定可靠，有些MCU支持禁止reset pin或者可以将其复用为输出以降低受到干扰后复位的现象。但是有些MCU不支持该功能，这种情况下就比较考验硬件攻城狮的经验了。最后再唠10块钱儿的，工艺越先进，EMC越有挑战。

2.1.3 Flash编程

大多数MCU都是内置Flash并支持IAP的，使用过程中，还是要注意些好。当年美系大厂收购的Cortex-M3的MCU据说仅支持上百次的擦写。还有些MCU的等待延时需要设置大一些，否则也会出现读写不一致的情况。相关的参数Datasheet一般都会列出：

当然，这里面还有一个比较重要的问题就是每个sector的大小，因为我们知道Flash都需要先擦再写，所以一些解耦的变量希望各自独占一个sector，sector越小其利用率越高。

2.2 要命的低功耗

做低功耗的产品，对设计的要求会更高，因为它需要细细的扣每一个模块甚至每一个pin的功耗。而死机与无法唤醒本身又非常的相似，处理起来还是比较棘手的。这里仅提供些思路

1. 如果是软件唤醒后对标志判断出错导致的问题，功耗往往会比低功耗模式要大。
2. 有些低功耗模式BOD和看门狗是关着的，所以电源的波动确实会可能死机。
3. 电池供电的产品最好硬件上能获取电量并通知MCU做相应的处理。

2.3 程序猿的梦魇

还有些时候，MCU在受到一些外部干扰的时候，会出现一些错误，有些错误是可以软件恢复的，只要clear下寄存器就可以了，有些是不可恢复的，这个一般要靠看门狗。早几年遇到一个项目，现场发现一个板子无法工作，现象是Modbus通讯失败，但主循环的LED灯还在闪烁，说明MCU本身没有死掉，挂上仿真器查看，原来是UART口上出现了帧错误，而软件没有做相关的处理导致接收失败。只要在软件中添加相关的中断服务函数即可修复该Bug。

还有些时候，程序猿睡的太晚，迷迷糊糊做出一些Bug导致业务出错，这也是常有的事情，比如使用RTOS时没考虑优先级反转，几个任务相互卡死......

3. 故事结束

通过这些故事，我们明白了一个道理，想让灯儿不停，马儿就要吃饱。

我就是那个老司机：