最近一工程师向我反馈一个问题，Ta说：我程序会死在这一行，大概是什么原因？
以下是Ta所说程序会死的地方，
用过HAL库的童鞋应该比较熟悉这个函数，它是延时函数。
拿到工程代码后我就开始Debug之旅了，现象确实如Ta所说，刚开始Hal_delay函数调用没问题，但是过了几秒之后就卡住了。因为该函数的计时是依赖Systick中断，这个现象说明Systick中断进不去了，通过debug模式下Systick中断服务函数里加断点，可以验证这一点。但是为什么刚开始好好的，后面就进不去中断了呢?最初我想是不是Systick中断被关掉了，通过查看Systick寄存器，发现并没有，Systick依然在计时并且中断使能也没有关。
程序里初始化时开启了RTC中断，周期是1s，Systick中断周期是1ms。刚开始时这两个中断都能进，几秒之后这俩中断就都进不去了。
这个现象看起来确实挺诡异，因为给我的代码里糅杂了很多业务代码，写的也有点乱，看的我很烦躁，后来还是静下心来仔细的分析，找到了问题所在。
原因是这样：Ta在RTC的中断服务函数里，在某个分支函数里调用了Hal_delay函数。因为RTC的中断优先级和Systick中断优先级一样，所以Systick中断就进不去了，导致Hal_delay函数也就执行不过去了，所以就出现了所谓的卡死现象。之所以刚开始没问题，过了几秒才出问题，是因为刚开始前几秒的RTC中断服务函数里没有进到调用Hal_delay函数的那个分支处理里，Ta是在初始化几秒之后，设置了一个标志位，导致后来RTC中断处理里调用了Hal_delay函数。
问题找到了，如何解决呢？
最简单的方法是，把Systick和RTC的中断优先级设置不一样，让Systick优先级比RTC高一点，这样可以保证Systick中断能够打断RTC中断，从而不会卡死。
ARM Cortex MCU的中断控制器英文名叫做NVIC，Nested Vectored Interrupt Controller，翻译过来就是嵌套向量中断控制器，所谓中断嵌套是指当正在执行一个中断服务程序时，这时如果来了优先级更高的中断，新来的中断会打断原来还没有处理完的中断服务程序，等新中断处理完毕之后再回到原中断服务继续处理。
Cortex-M0/M0+中断优先级设置非常简单，只需要通过CMSIS标准接口函数__NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)即可完成，优先级只有4个，分别为0、1、2、3，数字越小优先级越高。
问题解决了，总结不能少：
1） 我当时找这个问题花了较长时间，反思一下，其实是可以更快的定位问题的。当卡死在Hal_delay函数时，首先应该去分析是哪里调用这个函数导致卡死的，因为工程里调用的地方有好多处，可以通过在可能出现问题的调用前给一个全局变量赋不同的值，卡住时看全局变量，就可以定位到是从哪里进去的。这样倒着往前推，可以更快的定位问题。
2） 通常情况下中断服务函数应该尽可能的短，最好不要在中断里做延时之类的占用CPU时间长的工作。这是什么原因呢？欢迎大家评论区留言讨论。
