一个跟STM32中断优先级有关的话题1

近日有人咨询问题如下：

“我用STM32F7 MCU开发产品，用到STemwin。在桌面有一个图标，点击图标后创建一个窗口，窗口中3个按钮，和1个listbox。点击窗口中的CANCEL按钮窗口关闭。当我多次打开关闭这个窗口时，程序就会死！经调试，程序是死在了硬件I2C的while循环中，如下代码中：

1. static
   
2. HAL_StatusTypeDef I2C_WaitOnFlagUntilTimeout(I2C_HandleTypeDef *hi2c, uint32_t
   
3. Flag, FlagStatus Status, uint32_t Timeout)
   
4. {
   
5.   uint32_t tickstart = HAL_GetTick();
   
6.     /* Wait until flag is set */
   
7.   if(Status == RESET)
   
8.   {   
   
9.     while(__HAL_I2C_GET_FLAG(hi2c, Flag) ==
   
10. RESET)
    
11.     {
    
12.       /* Check for the Timeout */
    
13.       if(Timeout != HAL_MAX_DELAY)
    
14.       {
    
15.         if((Timeout == 0)||((HAL_GetTick() -
    
16. tickstart ) > Timeout))
    
17.         {
    
18.           hi2c->State= HAL_I2C_STATE_READY;
    
19.           /* Process Unlocked */
    
20.           __HAL_UNLOCK(hi2c);
    
21.           return HAL_TIMEOUT;
    
22.         }
    
23.       }
    
24.     }
    
25.   }

复制代码

或者

1. static
   
2. HAL_StatusTypeDef I2C_IsAcknowledgeFailed(I2C_HandleTypeDef *hi2c, uint32_t
   
3. Timeout)
   
4. {
   
5.   uint32_t tickstart = 0x00;
   
6.   tickstart = HAL_GetTick();
   
7. 
   
8.   if(__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_AF) ==
   
9. SET)
   
10.   {
    
11.     /* Wait until STOP Flag is reset */
    
12.     /* AutoEnd should be initiate after AF */
    
13.     while(__HAL_I2C_GET_FLAG(hi2c,
    
14. I2C_FLAG_STOPF) == RESET)
    
15.     {
    
16.       /* Check for the Timeout */
    
17.       if(Timeout != HAL_MAX_DELAY)
    
18.       {
    
19.         if((Timeout == 0)||((HAL_GetTick() -
    
20. tickstart ) > Timeout))
    
21.         {
    
22.           hi2c->State= HAL_I2C_STATE_READY;
    
23.           /* Process Unlocked */
    
24.           __HAL_UNLOCK(hi2c);
    
25.           return HAL_TIMEOUT;
    
26.         }
    
27.       }
    
28.     }...........

复制代码

该I2C程序是操作电阻触摸屏芯片的，由TIMER3定时器定时调用它。timer3中断优先级是[0,1]。I2C程序中超时检测是用的SYSTICK,其中断优先级是[0x0f,0]（第一个数字为抢占优先级，第二个数字为响应优先级）。

调试发现，程序死掉后，HAL_GetTick() 返回值始终不变，这样才进入死循环！

怀疑是systick优先级低，将其改为[0,0]最高优先级后，依然会进入上面的死循环！”

很明显，上面用户代码是基于STM32cube库实现的。根据上面用户反馈的问题描述，他是说程序有时会死掉，而且总死在I2C通信代码里。这个I2C通信代码是通过TIM3的中断调用的，其中I2C通信中的TIMEOUT超时检测又是依据SYSTICK中断计时实现。【注：用户设计的合理性，这里暂且不谈】

应该说用户已经意识到问题的原因了。如果SYSTICK优先级低于TIM3中断优先级，而I2C通信又是在TIM3中断里执行，那在I2C程序运行过程中SYSTICK中断就没法响应，无法进行TICK计数的加减。如果此时I2C通信出现故障，TIMOUT超时检测条件就永远不会成立。程序当然就卡死在那里面了。

后来用户将SYSTICK的优先级从之前的【0x0f,0】调整为【0,0】后现象仍未改善。他认为【0,0】是最高了。其实，此时SYSTICK的抢占优先级与TIM3抢占优先级是一样的，只是二者响应优先级不一样。如果这样的话，在TIM3 中断服务程序里，SYSTICK仍然无法响应中断进行计数，也就无法通过TIMEOUT检测退出死循环。

如果反过来，将SYSTICK的抢占优先级设置得比TIM3的抢占优先级高，情况就不同了。比方将SYSTICK的优先级配置为【0,0】，TIM3的优先级配置为【1,0】。如果这样，TIM3中断里调用I2C通信程序，如果I2C通信出现故障，TIMEOUT超时检测就不会受阻卡死。因为此时SYSTICK的抢占优先级高于TIM3的,它可以打断TIM3中断程序进行TICK的计数计时，当I2C程序检测到TIMEOUT成立时就可以全身而退了。后来建议用户如此调整的确改善。

小结下，问题源于用户对中断优先级的理解不到位。在MCU开发应用中因为中断优先级处理不当而导致困扰其实还挺多的，而且问题往往还比较隐蔽。

顺便提醒下：对于STM32F7/F4/F3/F1/L1/L4系列芯片的中断优先级往往分为抢占优先级和响应优先级。只有抢占优先级不同时才会发生中断的打断和嵌套。如果抢占优先级一样的话，在同时发生中断事件时，响应优先级高的中断源优先得到响应。如果抢占优先级和响应优先级也一样，同时发生中断时根据其中断向量表的序号决定。

对于基于CORTEX M0/M0+的STM32F0/L0系列，它们的中断优先级只有抢占优先级，不分响应优先级。

文章出处： 茶话MCU