我程序會死在這一行，是什么原因？

最近一工程師向我反饋一個問題，Ta說：我程序會死在這一行，大概是什么原因？

以下是Ta所說程序會死的地方，

用過HAL庫的童鞋應(yīng)該比較熟悉這個函數(shù)，它是延時函數(shù)。

拿到工程代碼后我就開始Debug之旅了，現(xiàn)象確實如Ta所說，剛開始Hal_delay函數(shù)調(diào)用沒問題，但是過了幾秒之后就卡住了。因為該函數(shù)的計時是依賴Systick中斷，這個現(xiàn)象說明Systick中斷進(jìn)不去了，通過debug模式下Systick中斷服務(wù)函數(shù)里加斷點(diǎn)，可以驗證這一點(diǎn)。但是為什么剛開始好好的，后面就進(jìn)不去中斷了呢?最初我想是不是Systick中斷被關(guān)掉了，通過查看Systick寄存器，發(fā)現(xiàn)并沒有，Systick依然在計時并且中斷使能也沒有關(guān)。

程序里初始化時開啟了RTC中斷，周期是1s，Systick中斷周期是1ms。剛開始時這兩個中斷都能進(jìn)，幾秒之后這倆中斷就都進(jìn)不去了。

這個現(xiàn)象看起來確實挺詭異，因為給我的代碼里糅雜了很多業(yè)務(wù)代碼，寫的也有點(diǎn)亂，看的我很煩躁，后來還是靜下心來仔細(xì)的分析，找到了問題所在。

原因是這樣：Ta在RTC的中斷服務(wù)函數(shù)里，在某個分支函數(shù)里調(diào)用了Hal_delay函數(shù)。因為RTC的中斷優(yōu)先級和Systick中斷優(yōu)先級一樣，所以Systick中斷就進(jìn)不去了，導(dǎo)致Hal_delay函數(shù)也就執(zhí)行不過去了，所以就出現(xiàn)了所謂的卡死現(xiàn)象。之所以剛開始沒問題，過了幾秒才出問題，是因為剛開始前幾秒的RTC中斷服務(wù)函數(shù)里沒有進(jìn)到調(diào)用Hal_delay函數(shù)的那個分支處理里，Ta是在初始化幾秒之后，設(shè)置了一個標(biāo)志位，導(dǎo)致后來RTC中斷處理里調(diào)用了Hal_delay函數(shù)。

問題找到了，如何解決呢？

最簡單的方法是，把Systick和RTC的中斷優(yōu)先級設(shè)置不一樣，讓Systick優(yōu)先級比RTC高一點(diǎn)，這樣可以保證Systick中斷能夠打斷RTC中斷，從而不會卡死。

ARM Cortex MCU的中斷控制器英文名叫做NVIC，Nested Vectored Interrupt Controller，翻譯過來就是嵌套向量中斷控制器，所謂中斷嵌套是指當(dāng)正在執(zhí)行一個中斷服務(wù)程序時，這時如果來了優(yōu)先級更高的中斷，新來的中斷會打斷原來還沒有處理完的中斷服務(wù)程序，等新中斷處理完畢之后再回到原中斷服務(wù)繼續(xù)處理。

Cortex-M0/M0+中斷優(yōu)先級設(shè)置非常簡單，只需要通過CMSIS標(biāo)準(zhǔn)接口函數(shù)__NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)即可完成，優(yōu)先級只有4個，分別為0、1、2、3，數(shù)字越小優(yōu)先級越高。

問題解決了，總結(jié)不能少：

1） 我當(dāng)時找這個問題花了較長時間，反思一下，其實是可以更快的定位問題的。當(dāng)卡死在Hal_delay函數(shù)時，首先應(yīng)該去分析是哪里調(diào)用這個函數(shù)導(dǎo)致卡死的，因為工程里調(diào)用的地方有好多處，可以通過在可能出現(xiàn)問題的調(diào)用前給一個全局變量賦不同的值，卡住時看全局變量，就可以定位到是從哪里進(jìn)去的。這樣倒著往前推，可以更快的定位問題。

2） 通常情況下中斷服務(wù)函數(shù)應(yīng)該盡可能的短，最好不要在中斷里做延時之類的占用CPU時間長的工作。這是什么原因呢？歡迎大家評論區(qū)留言討論。

關(guān)注公眾號，掃碼加入嵌入式交流群：