uc-OS III 任務優先級不當引發的困擾
前言
為了使STM32的生態系統里OS多元化，stm32系列不僅支持FreeRTOS,也支持uc-OSIII，提供給客戶更多選擇，滿足客戶日益增長的需求。
這里使用stm32f429-eval平臺，基于stm32cubef4中的Demostration例程，替換其中的FreeRTOS。例程中uc-OSIII系統里涉及的任務及其優先級配置如下表：
Demostration 是一個綜合示例，包含了盡可能多的中間件，譬如GUI framework, STemwin,USB stack, FatFS, OS(FreeRTOS)等等。鑒于芯片內存大小限制，在stm32f429-eval 平臺上，tcp/ipstack lwIP 并未集成進去。
Case 1 優先級設置不當引發ANR(application not response)
1.1 問題描述
在應用中，有一個videoplayer 和audioplayer 模塊，其中有一個功能，從文件系統中向播放器添加文件、文件夾，這在emWinframework 中，通過控件CHOOSEFILE_Create實現，它是一個基于窗口的模式對話框。
然而，只要點擊“+”按鈕或者文件夾按鈕后，彈出一個選擇文件的對話框，再點擊屏幕任何地方，系統都沒有任何反應，界面也一直停留在這個對話框。
1.2 問題分析與定位
在uc-OSIII 中，觸摸屏事件是通過軟定時器實現的，軟件定時器是通過一個任務實現的，而當定時器任務的優先級比GUI任務低時，當GUI任務處于就緒狀態時，定時器任務得不到任何調度，那么任何觸摸事件的更新消息無法產生，也無法發送給GUI任務，而GUI任務在等待觸摸事件（GUI任務與觸摸模塊是通過信號量來同步的）。這樣就出現了deadlock,一方（消費者）死等某個事件的產生，而另外一方（生產者）無法產生這個事件，系統就出現了無響應的現象。
1.3 問題解決方案
既然uc-OSIII 是搶占式調度模式（也支持round-robbin調度），那么將定時器任務優先級調整比GUI任務優先級高一級即可，問題予以解決。
Case 2 優先級設置不當引發調試模式下，程序崩潰
2.1 問題描述：
使用Keil5.20 版本編譯、調試、下載程序時，如果程序處于運行模式，一切正常；然而如果置于調試模式，則程序100%crash。這種情形十分罕見，一般情況下是，運行模式往往程序會crash,調試模式下，程序可以正常運行。使用調試模式來troubleshootbug 的。
2.2 問題分析&解決
幸運的是，該問題100%復現。于是竭盡全力去找尋上一次對程序的修改導致了此問題，一步一步撤銷修改，恢復成代碼的初始狀態。經過幾番努力，力爭追根溯源，想查明是哪一次的修改導致了問題。結果，依然一無所獲。
于是，開始考慮從異常處理程序中著手，找到觸發異常的那條指令，那個函數，那個任務。這里主要參考了ARM提供的應用筆記《apnt209.pdf》。調試時，通過FaultReport 知悉，此異常為busfault,而且BFARVALID和PRECISERR都置位了。按照ARM的指南，BFARVALID 對應的地址寄存器存儲的是觸發busfault 的指令地址，不過這次失效了，里面的地址不在ROM地址范圍內。
本想咨詢一下ARM的技術支持，如何解決這一問題。因為個人覺得，這個問題跟調試器有關，懷疑是自己對于IDE的某些參數配置不當才引起的。苦于沒有任何間接的、直接的來自ARM官方的關于KeilMDK 技術支持。未遂。
心痛還得心藥治，解鈴還須系鈴人。考慮系統存在諸多任務，于是考慮通過WBS方式，一一注釋掉這些任務，看看究竟是哪個任務引起的。這樣做的話，工作量比較大。退而求其次，既然調試時程序每次都crash，而且每次crash時，內核的寄存器參數的值都是一樣的（幸運的是，該異常不是隨機產生的），聯想到Linux內核里有一個當前任務指針currenttask pointer,而uc-OSIII 中也有類似的數據結構（其他OS如FreeRTOS也有類似數據結構），即OSTCBCurPtr，將其置于watch窗口，發現其指向OSStatTaskTCB,于是在stat 任務相應
的任務處理函數設置斷點，單步執行，這樣居然程序可以正常運行！
進一步發現，在系統啟動過程中，stat任務會統計每個任務占用CPU時間，比較耗費CPU,導致GUI 任務不能及時執行，從而誘發總線異常（busfault）。于是嘗試將stat任務優先級調低，重新編譯、下載、調試，一切OK!運行模式也OK.
OMG，原來是stat 任務優先級設置過高導致了bus fault !還是任務優先級安排不當導致的問題。
STM32/STM8 意法半導體/ST/STM
編輯：admin 最后修改時間：2019-01-03
