STM32F030在低溫下無法啟動(dòng)

問題描述

客戶反饋STM32F030作為他們產(chǎn)品的控制芯片，在常溫下工作是正常的，但是稍微冷凍下就會(huì)啟動(dòng)失敗，重現(xiàn)率100%，再次加熱或者恢復(fù)到常溫又能正常工作。

此問題已經(jīng)困擾了客戶四五年，一直沒有頭緒，每次都更換一塊芯片就好了，因?yàn)榭蛻糇约阂仓?，換芯片時(shí)會(huì)將其吹下來，必定會(huì)加熱芯片，這樣MCU也就能恢復(fù)正常了。但這種辦法終究不是解決方法，客戶急切想找到原因并解決問題。

分析問題與解決

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

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

結(jié)果顯示，STM32F030-NUCLEO板能正常啟動(dòng)，而客戶的板子問題重現(xiàn)，再次測量其VDD和NRST的啟動(dòng)波形，發(fā)現(xiàn)VDD上電過程中有稍微不規(guī)則波形，但感覺不至于導(dǎo)致MCU無法啟動(dòng)?？紤]到當(dāng)前客戶板子上的MCU跑的是客戶自己的程序，為了統(tǒng)一對比，將客戶板子上的MCU燒錄成NUCELO板上一樣的程序，再次做低溫測試，結(jié)果顯示客戶的板子也能正常啟動(dòng)！

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

接下來對比測試代碼與客戶自己的代碼，并再次做低溫測試驗(yàn)證結(jié)果，最終發(fā)現(xiàn)客戶的時(shí)鐘樹配置有個(gè)參數(shù)有問題：

Figure 1

如上紅色代碼所示，

RCC_OSCILLATORTYPE_NONE

改成RCC_OSCILLATORTYPE_HSI后，

問題現(xiàn)象明顯改善，但經(jīng)過測試，發(fā)現(xiàn)偶爾還會(huì)啟動(dòng)不正常的時(shí)候。但相對于之前100%可以重現(xiàn)的現(xiàn)象，至少說明之前軟件的失誤至少是一個(gè)因素。

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

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

至此，問題解決！

后話

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

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

來源： STM32單片機(jī)


審核編輯：湯梓紅