銷售GG在工作群里：“弟兄們，快醒醒，咱現場的跑馬燈不跑了?！?/p>

還在加班的程序猿：“已經查過了，程序沒Bug?！?/p>

帶娃玩的硬件攻城獅：“硬件沒問題，這都是照官方Demo弄的。”

刷劇的測試MM小聲嘀咕：“我可都是按用例測的，沒出問題啊。”

還是攻城獅有主意：“要不叫FAE過來看看？”

“好好好”，意見終于統一了，FAE也該起床換衣服了。..。..

作為21世紀的嵌入式攻城獅，誰還沒見過MCU死機啊，作為一個二手的程序猿，也見過大大小小的事故現場，于是乎，經過半個多月的思想斗爭，我最后做出了一個違背祖宗的決定，把祖傳百年的秘法無償的獻給國家。

1. 現場講故事弟兄們終于盼來了FAE，拉上手，快坐下，咱們說說知心話：“是你芯片問題吧，快點認了哈，這才好給老板交代啊?！?/p>

FAE：“GG，這恐怕不好吧，咱先看是不是馬累了，跑不動了，要休息啊?！?/p>

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

FAE：“沒關系，我們還是先坐下，從頭捋一把，看看下面這張圖，聽我講講故事吧?！?/p>

2. 故事開始MCU死機一定是有原因的，往往有的流于表面，有的隱藏很深，特別是那種偶發的故障，直讓人掉頭發，遇到這種情況，最擔心的恐怕就是程序猿了，所以看一個程序猿的水平從脫帽開始，而死機的問題，需要從查找現象開始。下面的故事分享會按照圖中的現象標號來講述，我們先進入第一個故事：

1.1.1電源的故事MCU上電就不能工作，肯定會先看電源，結果有兩種：

電源有問題：這種情況下，硬件攻城獅應該就沖上來了，檢查硬件設計或生成問題，比如峰值電源超過設計Spec，原理圖/PCB是否設計有問題，板子焊接是否正確。

電源沒問題：等等，電源沒問題，怎么還能歸出這個問題呢？當然有可能，你見過畫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可以讓輸入電壓達到比較高的值后再打開輸出，以保證后級輸出的線性及斜率夠快。

如果真掉到坑里會出現什么結果呢，送大家幾個知識點：

MCU停機無法啟動，這是大家都不愿意看到的

MCU偏偏能啟動，還能工作，但是內部模塊初始化不完全導致功能異常，最常見的是Memory

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的功耗。而死機與無法喚醒本身又非常的相似，處理起來還是比較棘手的。這里僅提供些思路

如果是軟件喚醒后對標志判斷出錯導致的問題，功耗往往會比低功耗模式要大。

有些低功耗模式BOD和看門狗是關著的，所以電源的波動確實會可能死機。

電池供電的產品最好硬件上能獲取電量并通知MCU做相應的處理。

2.3 程序猿的夢魘還有些時候，MCU在受到一些外部干擾的時候，會出現一些錯誤，有些錯誤是可以軟件恢復的，只要clear下寄存器就可以了，有些是不可恢復的，這個一般要靠看門狗。早幾年遇到一個項目，現場發現一個板子無法工作，現象是Modbus通訊失敗，但主循環的LED燈還在閃爍，說明MCU本身沒有死掉，掛上仿真器查看，原來是UART口上出現了幀錯誤，而軟件沒有做相關的處理導致接收失敗。只要在軟件中添加相關的中斷服務函數即可修復該Bug。

還有些時候，程序猿睡的太晚，迷迷糊糊做出一些Bug導致業務出錯，這也時常有的事情，比如使用RTOS時沒考慮優先級反轉，幾個任務相互卡死。..。..

3. 故事結束通過這些故事，我們明白了一個道理，想讓燈兒不停，馬兒就要吃飽。

責任編輯：haq