前语
为了使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 !仍是使命优先级组织不妥导致的问题。
