uc-OS III 任务优先级不当引发的困扰

分享到:

前言
为了使STM32的生态系统里OS多元化,stm32系列不仅支持FreeRTOS,也支持uc-OSIII,提供给客户更多选择,满足客户日益增长的需求。
这里使用stm32f429-eval平台,基于stm32cubef4中的Demostration例程,替换其中的FreeRTOS。例程中uc-OSIII系统里涉及的任务及其优先级配置如下表:

1

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 !还是任务优先级安排不当导致的问题。

 

 
 
 
继续阅读
意法半导体推出48引脚封装 扩大市面上唯一支持LoRa®的STM32WL系统芯片的选择范围

中国,2020年8月28日——意法半导体为其获奖产品STM32WLE5 *无线系统芯片(SoC)的产品组合新增一款QFN48封装,将该产品的诸多集成功能、能效性和多调制的灵活性赋能到多种工业无线应用上。

意法半导体发布STM32状态监测功能包,通过Cartesiam工具简化机器学习过程

中国,2020年7月29日——意法半导体发布一款免费的STM32软件功能包,让用户可以用微控制器探索套件快速创建、训练、部署工业状态监测智能边缘设备。

意法半导体为STM32Cube®生态系统增添新功能,提高软件开发效率

中国,2020年7月28日——意法半导体STM32Cube®软件开发生态系统发布软件更新,让用户更轻松地筛选软件示例,搜集和使用开发工具,自定义、使用和分享STM32Cube扩展软件包。

意法半导体通过两项并购,进一步增强STM32微控制器的无线连接功能

中国, 2020年7月20 日 – 横跨多重电子应用领域的全球领先的半导体供应商意法半导体,于日前宣布签署两项并购协议,收购超宽带技术专业设计公司BeSpoon的全部股本和Riot Micro公司的蜂窝物联网连接资产。在两项交易走完正常监管审批手续成交后,意法半导体将进一步提升其在无线连接技术方面的服务,特别是完善STM32微控制器和安全微控制器的产品规划。

让汽车ECU开发事半功倍,ST AutoDevKit工具包长啥样?

STM32 是工业和消费市场上非常成功的微控制器解决方案,SPC5 系列汽车微控制器也许大家还不大熟悉,不过在 AutoDevKit 生态匹配搭建的强大加持下,站在使用者的角度来看待问题,解决对方行业痛点,未来的 SPC5 也许可以成为汽车电子界的 STM32 也是很有可能的。