久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

標題: 一個跟STM32中斷優先級有關的話題 [打印本頁]

作者: taoran 時間: 2016-6-17 01:38
標題: 一個跟STM32中斷優先級有關的話題
近日有人咨詢問題如下：
“我用STM32F7 MCU開發產品，用到STemwin。在桌面有一個圖標，點擊圖標后創建一個窗口，窗口中3個按鈕，和1個listbox。點擊窗口中的CANCEL按鈕窗口關閉。當我多次打開關閉這個窗口時，程序就會死！經調試，程序是死在了硬件I2C的while循環中，如下代碼中：
static
HAL_StatusTypeDef I2C_WaitOnFlagUntilTimeout(I2C_HandleTypeDef *hi2c, uint32_t
Flag, FlagStatus Status, uint32_t Timeout)

{
  uint32_t tickstart = HAL_GetTick();
/* Wait until flag is set */
  if(Status == RESET)
  {
while(__HAL_I2C_GET_FLAG(hi2c, Flag) ==
RESET)
{
   /* Check for the Timeout */
   if(Timeout != HAL_MAX_DELAY)
   {
      if((Timeout == 0)||((HAL_GetTick() -
tickstart ) > Timeout))
      {
      hi2c->State= HAL_I2C_STATE_READY;
      /* Process Unlocked */
      __HAL_UNLOCK(hi2c);
      return HAL_TIMEOUT;
      }
   }
}
  }...........省略

或者
static
HAL_StatusTypeDef I2C_IsAcknowledgeFailed(I2C_HandleTypeDef *hi2c, uint32_t
Timeout)
{
  uint32_t tickstart = 0x00;
  tickstart = HAL_GetTick();

  if(__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_AF) ==
SET)
  {
/* Wait until STOP Flag is reset */
/* AutoEnd should be initiate after AF */
while(__HAL_I2C_GET_FLAG(hi2c,
I2C_FLAG_STOPF) == RESET)
{
   /* Check for the Timeout */
   if(Timeout != HAL_MAX_DELAY)
   {
      if((Timeout == 0)||((HAL_GetTick() -
tickstart ) > Timeout))
      {
      hi2c->State= HAL_I2C_STATE_READY;
      /* Process Unlocked */
      __HAL_UNLOCK(hi2c);
      return HAL_TIMEOUT;
      }
   }
}...........省略

該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系列，它們的中斷優先級只有搶占優先級，不分響應優先級。

相關話題：
      STM32系列MCU芯片開關總中斷的話題

歡迎光臨 (http://m.zg4o1577.cn/bbs/)