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

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

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

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

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

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

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

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

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

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

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

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

問題解決了，總結不能少：

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

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

關注公眾號，掃碼加入嵌入式交流群：