|
|
近日有人咨詢問(wèn)題如下：
“我用STM32F7 MCU開(kāi)發(fā)產(chǎn)品，用到STemwin。在桌面有一個(gè)圖標(biāo)，點(diǎn)擊圖標(biāo)后創(chuàng)建一個(gè)窗口，窗口中3個(gè)按鈕，和1個(gè)listbox。點(diǎn)擊窗口中的CANCEL按鈕窗口關(guān)閉。當(dāng)我多次打開(kāi)關(guān)閉這個(gè)窗口時(shí)，程序就會(huì)死！經(jīng)調(diào)試，程序是死在了硬件I2C的while循環(huán)中，如下代碼中：
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定時(shí)器定時(shí)調(diào)用它。timer3中斷優(yōu)先級(jí)是[0,1。I2C程序中超時(shí)檢測(cè)是用的SYSTICK,其中斷優(yōu)先級(jí)是[0x0f,0（第一個(gè)數(shù)字為搶占優(yōu)先級(jí)，第二個(gè)數(shù)字為響應(yīng)優(yōu)先級(jí)）。
調(diào)試發(fā)現(xiàn)，程序死掉后，HAL_GetTick() 返回值始終不變，這樣才進(jìn)入死循環(huán)！
懷疑是systick優(yōu)先級(jí)低，將其改為[0,0最高優(yōu)先級(jí)后，依然會(huì)進(jìn)入上面的死循環(huán)！”
很明顯，上面用戶代碼是基于STM32cube庫(kù)實(shí)現(xiàn)的。根據(jù)上面用戶反饋的問(wèn)題描述，他是說(shuō)程序有時(shí)會(huì)死掉，而且總死在I2C通信代碼里。這個(gè)I2C通信代碼是通過(guò)TIM3的中斷調(diào)用的，其中I2C通信中的TIMEOUT超時(shí)檢測(cè)又是依據(jù)SYSTICK中斷計(jì)時(shí)實(shí)現(xiàn)�！咀ⅲ河脩粼O(shè)計(jì)的合理性，這里暫且不談】
應(yīng)該說(shuō)用戶已經(jīng)意識(shí)到問(wèn)題的原因了。如果SYSTICK優(yōu)先級(jí)低于TIM3中斷優(yōu)先級(jí)，而I2C通信又是在TIM3中斷里執(zhí)行，那在I2C程序運(yùn)行過(guò)程中SYSTICK中斷就沒(méi)法響應(yīng)，無(wú)法進(jìn)行TICK計(jì)數(shù)的加減。如果此時(shí)I2C通信出現(xiàn)故障，TIMOUT超時(shí)檢測(cè)條件就永遠(yuǎn)不會(huì)成立。程序當(dāng)然就卡死在那里面了。
后來(lái)用戶將SYSTICK的優(yōu)先級(jí)從之前的【0x0f,0】調(diào)整為【0,0】后現(xiàn)象仍未改善。他認(rèn)為【0,0】是最高了。其實(shí)，此時(shí)SYSTICK的搶占優(yōu)先級(jí)與TIM3搶占優(yōu)先級(jí)是一樣的，只是二者響應(yīng)優(yōu)先級(jí)不一樣。如果這樣的話，在TIM3 中斷服務(wù)程序里，SYSTICK仍然無(wú)法響應(yīng)中斷進(jìn)行計(jì)數(shù)，也就無(wú)法通過(guò)TIMEOUT檢測(cè)退出死循環(huán)。
如果反過(guò)來(lái)，將SYSTICK的搶占優(yōu)先級(jí)設(shè)置得比TIM3的搶占優(yōu)先級(jí)高，情況就不同了。比方將SYSTICK的優(yōu)先級(jí)配置為【0,0】，TIM3的優(yōu)先級(jí)配置為【1,0】。如果這樣，TIM3中斷里調(diào)用I2C通信程序，如果I2C通信出現(xiàn)故障，TIMEOUT超時(shí)檢測(cè)就不會(huì)受阻卡死。因?yàn)榇藭r(shí)SYSTICK的搶占優(yōu)先級(jí)高于TIM3的,它可以打斷TIM3中斷程序進(jìn)行TICK的計(jì)數(shù)計(jì)時(shí)，當(dāng)I2C程序檢測(cè)到TIMEOUT成立時(shí)就可以全身而退了。后來(lái)建議用戶如此調(diào)整的確改善。
小結(jié)下，問(wèn)題源于用戶對(duì)中斷優(yōu)先級(jí)的理解不到位。在MCU開(kāi)發(fā)應(yīng)用中因?yàn)橹袛鄡?yōu)先級(jí)處理不當(dāng)而導(dǎo)致困擾其實(shí)還挺多的，而且問(wèn)題往往還比較隱蔽。
順便提醒下：對(duì)于STM32F7/F4/F3/F1/L1/L4系列芯片的中斷優(yōu)先級(jí)往往分為搶占優(yōu)先級(jí)和響應(yīng)優(yōu)先級(jí)。只有搶占優(yōu)先級(jí)不同時(shí)才會(huì)發(fā)生中斷的打斷和嵌套。如果搶占優(yōu)先級(jí)一樣的話，在同時(shí)發(fā)生中斷事件時(shí)，響應(yīng)優(yōu)先級(jí)高的中斷源優(yōu)先得到響應(yīng)。如果搶占優(yōu)先級(jí)和響應(yīng)優(yōu)先級(jí)也一樣，同時(shí)發(fā)生中斷時(shí)根據(jù)其中斷向量表的序號(hào)決定。
對(duì)于基于CORTEX M0/M0+的STM32F0/L0系列，它們的中斷優(yōu)先級(jí)只有搶占優(yōu)先級(jí)，不分響應(yīng)優(yōu)先級(jí)。
相關(guān)話題：
STM32系列MCU芯片開(kāi)關(guān)總中斷的話題
|
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
