<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 嵌入式系統(tǒng) > 設計應用 > uc-OS III 任務優(yōu)先級不當引發(fā)的困擾

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

          作者: 時間:2016-11-13 來源:網(wǎng)絡 收藏
          前言

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

          本文引用地址:http://www.ex-cimer.com/article/201611/316125.htm

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

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

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

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

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

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

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

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

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

          本想咨詢一下ARM的技術支持,如何解決這一問題。因為個人覺得,這個問題跟調(diào)試器有關,懷疑是自己對于IDE的某些參數(shù)配置不當才引起的。苦于沒有任何間接的、直接的來自ARM官方的關于KeilMDK 技術支持。未遂。

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

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

          OMG,原來是stat 任務優(yōu)先級設置過高導致了bus fault !還是任務優(yōu)先級安排不當導致的問題。



          評論


          相關推薦

          技術專區(qū)

          關閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();