問題描述

客戶反饋STM32F030作為他們產品的控制芯片，在常溫下工作是正常的，但是稍微冷凍下就會啟動失敗，重現率100%，再次加熱或者恢復到常溫又能正常工作。

此問題已經困擾了客戶四五年，一直沒有頭緒，每次都更換一塊芯片就好了，因為客戶自己也知道，換芯片時會將其吹下來，必定會加熱芯片，這樣MCU也就能恢復正常了。但這種辦法終究不是解決方法，客戶急切想找到原因并解決問題。

分析問題與解決

從客戶描述上來看，猜測很大可能是硬件問題，因此帶了一塊STM32F030-NUCLEO板過去，想著做個芯片交換測試看下結果。

到達客戶現場，了解到客戶只是使用了內部高速晶振HSI。先使用示波器抓下VDD和NRST的啟動波形，在常溫下發現并沒有明顯異常。于是做低溫測試，為了對比，基于STM32F030-NUCLEO板了寫了一個只使用內部高速晶振HSI , 翻轉一個LED燈的程序。

結果顯示，STM32F030-NUCLEO板能正常啟動，而客戶的板子問題重現，再次測量其VDD和NRST的啟動波形，發現VDD上電過程中有稍微不規則波形，但感覺不至于導致MCU無法啟動。考慮到當前客戶板子上的MCU跑的是客戶自己的程序，為了統一對比，將客戶板子上的MCU燒錄成NUCELO板上一樣的程序，再次做低溫測試，結果顯示客戶的板子也能正常啟動！

于是可以初步斷定，此問題與客戶自己的軟件有關，而與外圍電路無關。

接下來對比測試代碼與客戶自己的代碼，并再次做低溫測試驗證結果，最終發現客戶的時鐘樹配置有個參數有問題：

Figure 1

如上紅色代碼所示，

RCC_OSCILLATORTYPE_NONE

改成RCC_OSCILLATORTYPE_HSI后，

問題現象明顯改善，但經過測試，發現偶爾還會啟動不正常的時候。但相對于之前100%可以重現的現象，至少說明之前軟件的失誤至少是一個因素。

現在問題變成偶爾重現，已經向前邁進一大步。接下來懷疑與硬件有關了，理由是同樣的測試軟件跑在用戶的板子上和跑在NUCELO軟件上的結果不一致。

因此接下來首先對于用戶的板子的外圍電路與STM32F030-NUCLEO板子的外圍電路，發現客戶MCU的BOOT0引腳是懸空的，于是加上一個外部10K下拉電路，再次測試問題不再重現。

至此，問題解決！

后話

回過頭來看這個問題，發現客戶知道MCU使用的是HSI，可偏偏在代碼中配置時鐘樹時使用的晶振類型卻是NONE !這種問題現在看來是非常低級的問題，但在代碼量大，或者代碼迭代的過程中，之前寫代碼的人離職，后續接手的工程師又不能全盤了解所有代碼的情況下時就會變成非常束手無策，當碰到此類莫名其妙的問題，特別是無法判斷到底是硬件問題還是軟件問題的時候，保持清晰的思路是非常重要的。

這里我需要強調的是，最有效的解決方法就是快速找到一個 “參照物”，而ST的DEMO板和示例代碼就是在硬件上和軟件上扮演這樣一個參照物的角色。可以通過MCU交換測試來判斷是不是芯片外圍電路的問題或者芯片問題，可以使用Cube庫下的示例代碼，對比其運行結果來判斷是否與軟件有關。先從大方向明確問題到底是與硬件有關還是與軟件有關，然后再做下一步分析，這種方法希望讀者能有效掌握。

來源： STM32單片機


審核編輯：湯梓紅