uc-OS III 任務(wù)優(yōu)先級不當(dāng)引發(fā)的困擾

uc-OSIII任務(wù)優(yōu)先級不當(dāng)引發(fā)的困擾前言

為了使STM32的生態(tài)系統(tǒng)里OS多元化，stm32系列不僅支持FreeRTOS,也支持uc-OSIII，提供給客戶更多選擇，滿足客戶日益增長的需求。

這里使用stm32f429-eval平臺，基于stm32cubef4中的Demostration例程，替換其中的FreeRTOS。例程中uc-OSIII系統(tǒng)里涉及的任務(wù)及其優(yōu)先級配置如下表：Demostration是一個綜合示例，包含了盡可能多的中間件，譬如GUIframework,STemwin,USBstack,FatFS,OS(FreeRTOS)等等。鑒于芯片內(nèi)存大小限制，在stm32f429-eval平臺上，tcp/ipstacklwIP并未集成進(jìn)去。

Case1優(yōu)先級設(shè)置不當(dāng)引發(fā)ANR(applicationnotresponse)1.1問題描述

在應(yīng)用中，有一個videoplayer和audioplayer模塊，其中有一個功能，從文件系統(tǒng)中向播放器添加文件、文件夾，這在emWinframework中，通過控件CHOOSEFILE_Create實現(xiàn)，它是一個基于窗口的模式對話框。

然而，只要點擊“+”按鈕或者文件夾按鈕后，彈出一個選擇文件的對話框，再點擊屏幕任何地方，系統(tǒng)都沒有任何反應(yīng)，界面也一直停留在這個對話框。1.2問題分析與定位

在uc-OSIII中，觸摸屏事件是通過軟定時器實現(xiàn)的，軟件定時器是通過一個任務(wù)實現(xiàn)的，而當(dāng)定時器任務(wù)的優(yōu)先級比GUI任務(wù)低時，當(dāng)GUI任務(wù)處于就緒狀態(tài)時，定時器任務(wù)得不到任何調(diào)度，那么任何觸摸事件的更新消息無法產(chǎn)生，也無法發(fā)送給GUI任務(wù)，而GUI任務(wù)在等待觸摸事件（GUI任務(wù)與觸摸模塊是通過信號量來同步的）。這樣就出現(xiàn)了deadlock,一方（消費者）死等某個事件的產(chǎn)生，而另外一方（生產(chǎn)者）無法產(chǎn)生這個事件，系統(tǒng)就出現(xiàn)了無響應(yīng)的現(xiàn)象。1.3問題解決方案

既然uc-OSIII是搶占式調(diào)度模式（也支持round-robbin調(diào)度），那么將定時器任務(wù)優(yōu)先級調(diào)整比GUI任務(wù)優(yōu)先級高一級即可，問題予以解決。

Case2優(yōu)先級設(shè)置不當(dāng)引發(fā)調(diào)試模式下，程序崩潰2.1問題描述：

使用Keil5.20版本編譯、調(diào)試、下載程序時，如果程序處于運行模式，一切正常；然而如果置于調(diào)試模式，則程序100%crash。這種情形十分罕見，一般情況下是，運行模式往往程序會crash,調(diào)試模式下，程序可以正常運行。使用調(diào)試模式來troubleshootbug的。2.2問題分析&解決

幸運的是，該問題100%復(fù)現(xiàn)。于是竭盡全力去找尋上一次對程序的修改導(dǎo)致了此問題，一步一步撤銷修改，恢復(fù)成代碼的初始狀態(tài)。經(jīng)過幾番努力，力爭追根溯源，想查明是哪一次的修改導(dǎo)致了問題。結(jié)果，依然一無所獲。于是，開始考慮從異常處理程序中著手，找到觸發(fā)異常的那條指令，那個函數(shù)，那個任務(wù)。這里主要參考了ARM提供的應(yīng)用筆記《apnt209.pdf》。調(diào)試時，通過FaultReport知悉，此異常為busfault,而且BFARVALID和PRECISERR都置位了。按照ARM的指南，BFARVALID對應(yīng)的地址寄存器存儲的是觸發(fā)busfault的指令地址，不過這次失效了，里面的地址不在ROM地址范圍內(nèi)。本想咨詢一下ARM的技術(shù)支持，如何解決這一問題。因為個人覺得，這個問題跟調(diào)試器有關(guān)，懷疑是自己對于IDE的某些參數(shù)配置不當(dāng)才引起的。苦于沒有任何間接的、直接的來自ARM官方的關(guān)于KeilMDK技術(shù)支持。未遂。心痛還得心藥治，解鈴還須系鈴人?？紤]系統(tǒng)存在諸多任務(wù)，于是考慮通過WBS方式，一一注釋掉這些任務(wù)，看看究竟是哪個任務(wù)引起的。這樣做的話，工作量比較大。退而求其次，既然調(diào)試時程序每次都crash，而且每次crash時，內(nèi)核的寄存器參數(shù)的值都是一樣的（幸運的是，該異常不是隨機產(chǎn)生的），聯(lián)想到Linux內(nèi)核里有一個當(dāng)前任務(wù)指針currenttaskpointer,而uc-OSIII中也有類似的數(shù)據(jù)結(jié)構(gòu)（其他OS如FreeRTOS也有類似數(shù)據(jù)結(jié)構(gòu)），即OSTCBCurPtr，將其置于watch窗口，發(fā)現(xiàn)其指向OSStatTaskTCB,于是在stat任務(wù)相應(yīng)

的任務(wù)處理函數(shù)設(shè)置斷點，單步執(zhí)行，這樣居然程序可以正常運行！進(jìn)一步發(fā)現(xiàn)，在系統(tǒng)啟動過程中，stat任務(wù)會統(tǒng)計每個任務(wù)占用CPU時間，比較耗費CPU,導(dǎo)致GUI任務(wù)不能及時執(zhí)行，從而誘發(fā)總線異常（busfault）。于是嘗試將stat任務(wù)優(yōu)先級調(diào)低，