最近一工程师向我反馈一个问题,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时间长的工作。这是什么原因呢?欢迎大家评论区留言讨论。
关注公众号,扫码加入嵌入式交流群: