这些小活动你都参加了吗?快来围观一下吧!>>
电子产品世界 » 论坛首页 » 嵌入式开发 » STM32 » uc-OS III 任务优先级配置注意点

共2条 1/1 1 跳转至

uc-OS III 任务优先级配置注意点

助工
2016-10-13 11:00:34     打赏

本文原名为 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,而且BFARVALIDPRECISERR都置位了。按照ARM的指南,BFARVALID 对应的地址寄存器存储的是触发busfault 的指令地址,不过这次失效了,里面的地址不在ROM地址范围内。


本想咨询一下ARM的技术支持,如何解决这一问题。因为个人觉得,这个问题跟调试器有关,怀疑是自己对于IDE的某些参数配置不当才引起的。苦于没有任何间接的、直接的来自ARM官方的关于KeilMDK 技术支持。未遂。


心痛还得心药治,解铃还须系铃人。考虑系统存在诸多任务,于是考虑通过WBS方式,一一注释掉这些任务,看看究竟是哪个任务引起的。这样做的话,工作量比较大。退而求其次,既然调试时程序每次都crash,而且每次crash时,内核的寄存器参数的值都是一样的(幸运的是,该异常不是随机产生的),联想到Linux内核里有一个当前任务指针currenttask pointer,uc-OSIII 中也有类似的数据结构(其他OSFreeRTOS也有类似数据结构),OSTCBCurPtr,将其置于watch窗口,发现其指向OSStatTaskTCB,于是在stat 任务相应

的任务处理函数设置断点,单步执行,这样居然程序可以正常运行!


进一步发现,在系统启动过程中,stat任务会统计每个任务占用CPU时间,比较耗费CPU,导致GUI 任务不能及时执行,从而诱发总线异常(busfault)。于是尝试将stat任务优先级调低,重新编译、下载、调试,一切OK!运行模式也OK.


 OMG,原来是stat 任务优先级设置过高导致了bus fault !还是任务优先级安排不当导致的问题。





关键词: uc-OS     任务     优先级     配置    

高工
2016-10-20 19:39:52     打赏
2楼
顶一个

共2条 1/1 1 跳转至

回复

匿名不能发帖!请先 [ 登陆 注册 ]