请选择 进入手机版 | 继续访问电脑版

你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

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

[复制链接]
STMCU小助手 提问时间:2021-3-9 13:33 /
一个跟STM32中断优先级有关的话题1

4.1.jpg

近日有人咨询问题如下:

“我用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.   if(__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_AF) ==
  8. SET)
  9.   {
  10.     /* Wait until STOP Flag is reset */
  11.     /* AutoEnd should be initiate after AF */
  12.     while(__HAL_I2C_GET_FLAG(hi2c,
  13. I2C_FLAG_STOPF) == RESET)
  14.     {
  15.       /* Check for the Timeout */
  16.       if(Timeout != HAL_MAX_DELAY)
  17.       {
  18.         if((Timeout == 0)||((HAL_GetTick() -
  19. tickstart ) > Timeout))
  20.         {
  21.           hi2c->State= HAL_I2C_STATE_READY;
  22.           /* Process Unlocked */
  23.           __HAL_UNLOCK(hi2c);
  24.           return HAL_TIMEOUT;
  25.         }
  26.       }
  27.     }...........
复制代码

该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

收藏 评论0 发布时间:2021-3-9 13:33

举报

0个回答
关于意法半导体
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
招聘信息
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
关注我们
st-img 微信公众号
st-img 手机版