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

為了使STM32的生態(tài)系統里OS多元化，stm32系列不僅支持FreeRTOS,也支持uc-OSIII，提供給客戶(hù)更多選擇，滿(mǎn)足客戶(hù)日益增長(cháng)的需求。
這里使用stm32f429-eval平臺，基于stm32cubef4中的Demostration例程，替換其中的FreeRTOS。例程中uc-OSIII系統里涉及的任務(wù)及其優(yōu)先級配置如下表：

Demostration 是一個(gè)綜合示例，包含了盡可能多的中間件，譬如GUI framework, STemwin,USB stack, FatFS, OS(FreeRTOS)等等。鑒于芯片內存大小限制，在stm32f429-eval 平臺上，tcp/ipstack lwIP 并未集成進(jìn)去。

Case 1 優(yōu)先級設置不當引發(fā)ANR(application not response)

1.1 問(wèn)題描述
在應用中，有一個(gè)videoplayer 和audioplayer 模塊，其中有一個(gè)功能，從文件系統中向播放器添加文件、文件夾，這在emWinframework 中，通過(guò)控件CHOOSEFILE_Create實(shí)現，它是一個(gè)基于窗口的模式對話(huà)框。
然而，只要點(diǎn)擊“+”按鈕或者文件夾按鈕后，彈出一個(gè)選擇文件的對話(huà)框，再點(diǎn)擊屏幕任何地方，系統都沒(méi)有任何反應，界面也一直停留在這個(gè)對話(huà)框。

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

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

Case 2 優(yōu)先級設置不當引發(fā)調試模式下，程序崩潰

2.1 問(wèn)題描述：
使用Keil5.20 版本編譯、調試、下載程序時(shí)，如果程序處于運行模式，一切正常；然而如果置于調試模式，則程序100%crash。這種情形十分罕見(jiàn)，一般情況下是，運行模式往往程序會(huì )crash,調試模式下，程序可以正常運行。使用調試模式來(lái)troubleshootbug 的。

2.2 問(wèn)題分析&解決
幸運的是，該問(wèn)題100%復現。于是竭盡全力去找尋上一次對程序的修改導致了此問(wèn)題，一步一步撤銷(xiāo)修改，恢復成代碼的初始狀態(tài)。經(jīng)過(guò)幾番努力，力爭追根溯源，想查明是哪一次的修改導致了問(wèn)題。結果，依然一無(wú)所獲。

于是，開(kāi)始考慮從異常處理程序中著(zhù)手，找到觸發(fā)異常的那條指令，那個(gè)函數，那個(gè)任務(wù)。這里主要參考了ARM提供的應用筆記《apnt209.pdf》。調試時(shí)，通過(guò)FaultReport 知悉，此異常為busfault,而且BFARVALID和PRECISERR都置位了。按照ARM的指南，BFARVALID 對應的地址寄存器存儲的是觸發(fā)busfault 的指令地址，不過(guò)這次失效了，里面的地址不在ROM地址范圍內。

本想咨詢(xún)一下ARM的技術(shù)支持，如何解決這一問(wèn)題。因為個(gè)人覺(jué)得，這個(gè)問(wèn)題跟調試器有關(guān)，懷疑是自己對于IDE的某些參數配置不當才引起的?？嘤跊](méi)有任何間接的、直接的來(lái)自ARM官方的關(guān)于KeilMDK 技術(shù)支持。未遂。

心痛還得心藥治，解鈴還須系鈴人?？紤]系統存在諸多任務(wù)，于是考慮通過(guò)WBS方式，一一注釋掉這些任務(wù)，看看究竟是哪個(gè)任務(wù)引起的。這樣做的話(huà)，工作量比較大。退而求其次，既然調試時(shí)程序每次都crash，而且每次crash時(shí)，內核的寄存器參數的值都是一樣的（幸運的是，該異常不是隨機產(chǎn)生的），聯(lián)想到Linux內核里有一個(gè)當前任務(wù)指針currenttask pointer,而uc-OSIII 中也有類(lèi)似的數據結構（其他OS如FreeRTOS也有類(lèi)似數據結構），即OSTCBCurPtr，將其置于watch窗口，發(fā)現其指向OSStatTaskTCB,于是在stat 任務(wù)相應
的任務(wù)處理函數設置斷點(diǎn)，單步執行，這樣居然程序可以正常運行！

進(jìn)一步發(fā)現，在系統啟動(dòng)過(guò)程中，stat任務(wù)會(huì )統計每個(gè)任務(wù)占用CPU時(shí)間，比較耗費CPU,導致GUI 任務(wù)不能及時(shí)執行，從而誘發(fā)總線(xiàn)異常（busfault）。于是嘗試將stat任務(wù)優(yōu)先級調低，重新編譯、下載、調試，一切OK!運行模式也OK.

OMG，原來(lái)是stat 任務(wù)優(yōu)先級設置過(guò)高導致了bus fault !還是任務(wù)優(yōu)先級安排不當導致的問(wèn)題。