有STM32用户发现在操作BASEPRI特殊功能寄存器时,根本不起作用。比方,它目前配置了几个中断,优先级各不相同,按照STM32CubeMx里的配置分别为2、3、4不等,当他在BASEPRI寄存器里写这几个数字中的任意一个时,发现BASEPRI的数字始终是0,没有任何效果。
我们知道,通过配置 BASEPRI寄存器非0值来给系统中的中断响应设置门槛,当中断优先级低于某个级别时将不会得到CPU的响应执行,也就是说只有中断优先级高于某个级别时才能得到响应。下面截图是来自ARM CORTEX M4技术手册中有关BASEPRI寄存器的描述。
从这里可以看到该寄存器的有效配置位有8位,对其写0无意义,或者说放弃设置中断响应门槛功能。在ARMCORTEX-M内核系统里,中断优先级的高低跟表示优先级的数字大小成相反关系,即数字越小的中断优先级配置值所对应的优先级反而越高。
根据BASEPRI寄存器的定义,假设给BASEPRI写数字5,那就意味着只有中断优先级高于5的中断,即中断优先级的数字小于5的中断可以得到响应,而其它低于优先级5的中断将会被屏蔽。【注:这里说的优先级比较最终都体现在抢占优先级上】
另外,在ARM内核里关于每个中断的优先级配置寄存器也是8位,并支持字节访问。
内核里还有跟中断优先级有关的寄存器,它把中断优先级配置位分成2部分,用来分别设置每个中断的组优先级和子优先级,或称抢占优先级和响应优先级,也有称主优先级和子优先级的,意思都一样。个人喜欢中间的术语。
以上图优先级分组值【PRIGROUP】等于3为例。中断优先级寄存器中的bit0~bit3用作配置该中断的响应优先级,显然,它的值可以是0到15的任一值。bit4~bit7用来配置该中断的强占优先级,同样它的值也可以是0到15的任一值。若以【PRIGROUP】等于7为例,则所有可配置优先级的中断只配置响应优先级,不区分强占优先级,或者说抢占优先级都一样,或者说彼此不发生中断抢占都一个意思。所谓中断抢占即指另一中断事件打断正在执行的中断服务程序而响应更高优先级的程序。
上面都基于ARM Cortex-M内核的最初设计来说的,我们知道,STM32是基于ARM内核添加ST的外设而成,ST在设计芯片的中断优先级这个地方,在AMR核的设计基础上做了些针对性的调整,涉及中断优先级的寄存器的有效控制位由8位变成4位,且仅使用高4位,低4位变成保留位。【下图来自STM32Cortex M4 编程手册。注意红色下划线特别说明。】
不难理解,BASEPRI寄存器也会跟着做了调整,不然没法跟上面调整过的中断优先级寄存器匹配,它也只使用高4位,低4位变保留位。【下图来自STM32F4系列编程手册】
当然,关于优先级分组的控制寄存器的内容也做了相应调整,即针对优先级寄存器的高4位来划分抢占优先级和响应优先级的配置。详见下图:
把上图的各种优先级分组配置变得更直观点就是下图的样子。绿色用于配置抢占优先级,黄色用于配置响应优先级,灰色保留位,一共有5种可能的分组情形。
聊到这里,我们得知每个可配置的STM32片内中断,都有一个8位优先级配置寄存器与之对应,且只用到高4位。我们接着看看开篇的问题。目前STM32的有关中断配置如下图所示【使用STM32CubeMx工具进行】:
这里优先级分组选择的是将优先级的4位控制位全部用作抢占优先级的配置,响应优先级都一样,即不做特别配置。那么上图中SYSTICK/TIM2/TIM3/TIM4的中断的抢占优先级数据0、2、3、4其实是站在中断优先级寄存器的高4位而言的,那么放到整个8位优先级寄存器来看的话,他们的优先级应该是0x00,0x20,0x30,0x40【其实,低4位值是多少无关紧要,反正无效位】。
前面提过了,现在BASEPRI寄存器也只用到高4位,低4位保留。显然,如果在给BASEPRI寄存器赋值时按照基于高4位得到数字往里面写的话肯定都是无效的。
比方,我们期望在主程序里将上面TIM2/TIM3/TIM4的几个中断都屏蔽掉,若代码像下面截图里这样写肯定达不到目的。我这里开启了TIM2/TIM3/TIM4的周期性更新中断。【本文代码编译、调试基于ARM MDK IDE】
经过测试也的确没有达到目的。我写__set_BASEPRI(2)的本意是想屏蔽掉那几个定时器的中断响应,结果发现根本没作用。BASEPRI寄存器也没正确写入,因为数据2只能写到BASEPRI寄存器的低4位,这几位恰好是无效位。不难理解,当我们改写成__set_BASEPRI(0x20)时就可以达到目的了。
此时,BASEPRI被正确写入,TIM2/TIM3/TIM4的中断不能得到响应,倒是SYSTICK中断可以不被影响地得到响应,因为它的优先级是0,BASEPRI的配置屏蔽不了它。也就是说,通过配置BASEPRI寄存器来设置中断响应门槛的话,是阻止不了优先级为0或更高优先级的中断的响应的。如果对BASEPRI写0表示放弃其设置的中断门槛的功能。
如果希望对包括0优先级在内的所有可配置中断进行关闭或屏蔽,能否做得到呢?若可以,如何操作?
STM32芯片里的中断如果按中断源是来自ST外设还是ARM核处理器可以分为异常和中断,比方下图中灰色部分的就是异常,其它为中断。【截图来自STM32G4系列参考手册】
平常我们统称二者为中断,不做区分。如果说把所有中断按其优先级是否可以配置,又可以将中断分为优先级固定和优先级可配置的中断。其中,优先级固定的中断在上面表格中都明确标示了fixed字样,优先级可配置的都加注了settable字样。结合前面提到的优先级寄存器的特性,可配置的优先级是不会高于0级,即配置的数字不会小于0的。
若我们期望对所有可配置中断进行关闭或屏蔽,可以操作另一个叫PRIMASK的寄存器,它只有1位有效控制位。
我们通过对PARMASK写1,令CPU对所有优先级可配置的中断不做响应;若对其写0表示放弃屏蔽功能。比方,我们还是接着前面的演示代码来看看效果。
这时,前面提到的4个定时器中断都不能得到响应了,虽打了断点但过不去。我们还可以借助调试工具看到这几个中断的响应情况【SYSTICK位置离得远,单独截取后插进图中的】。
对于上图的部分信息我这里稍微解释下。
图形上方的字母E、P、A是下方Eable/Pending/Active单词的首字母。Enable表示相应中断是否在NVIC端得到响应允许;Pending表示中断等待CPU的执行;Active表示中断服务程序正在被执行。从图中可以看出,SYSTICK/TIM2/TIM3/TIM4的中断响应都虽得到允许,但都处于Pending期待执行状态。既然没有得到执行,Active位自然也是0。
上图中优先级的数字显然是按照高4位结合优先级分组后来看的,那个S表示SubPriority的意思。为了看得更清晰点,我不妨将优先级分组采用下面的做法重新配置下,保持原抢占优先级都不动,增加1位响应优先级【即子优先级】配置。目前4位优先级配置位拆分为3位抢占优先级配置位和1位响应优先级配置位。当前测试代码也保持不动。
显然,上图中的抢占优先级编号2、3、4是站在分组后的高3位单独来看的,响应优先级是站在分组后剩下的1位单独来看的。如果我们把两类优先级的配置合在高4位一起看,优先级数字应该分别是十进制数1、5、6、9。【这个地方要弄清楚,否则下面调试结果看不明白。】
基于前面测试代码和现有配置,我们看看运行后的中断响应情况。
刚才虽然调整了优先级的分组配置,但这几个中断的抢占优先级都没改变,所以在PRIMASK为1的情况下都不能得到响应。我们可以发现这几个中断的优先级站在高4位的角度来看而得出的优先级数字跟我上面分析的基本一致,除了SYSTICK的。
按理此时此处SYSTICK的优先级应该是1而不是0。为什么会这样呢?原因就在于我基于CubeMx组织的代码,这个过程中如果使用SYSTICK做库代码的TICK时钟,其中断优先级的配置使用默认配置,没有理睬CubeMx这边针对它子优先级的配置。Cube库在配置SYSTICK优先级时,默认使用全部4位用作抢占优先级的配置,同时将子优先级配置为0。当然,我们可以针对性地调整来适应我们的需求。主要是下面这个weak特性的初始函数,我们可以手动修改这个函数里关于中断优先级的配置。
关于使用PRIMASK屏蔽所有可配置中断的做法还有其它等效动作,比如使用CPSID指令和CPSIE指令或调用相关CMSIS函数。【参见下图】
它们的作用一样,也就是我们平常所说的开、关总中断,准确点说是屏蔽所有优先级可配置中断的响应或者放弃屏蔽功能。对于开、关总中断的说法,从实现屏蔽效果来看勉强可以说能关总中断。但整体上讲,个人觉得这个说法不太合适,还很容易给人带来误解,颇具误导性。其实,不论是操作PRIMASK还是BASEPRI寄存器,并没有对被屏蔽中断的原有参数和配置做任何改变。即那些暂时被屏蔽的中断的中断响应允许位、中断请求使能位、中断触发事件等都不会因为暂时的被屏蔽而发生改变。打个形象而不是特别贴切的比方。当你开着豪车愉快地跑在某条道上,听着歌哼着曲。突然前方有交警在对道路做临时管制,你和其它一干人车都被拦停下来。原因是有一行高级别的人物要保障优先通行。你等虽被拦停下来,既没人说你无证驾驶、也没人告知你无权走这条道,证照都在,行路权也有,就是此刻级别不够。一旦放行,你依然可以一如既往地行使。
我倒觉得ARM技术手册提到的优先级提升更好理解和接受些。即通过对BASEPRI、PRIMASK这些寄存器编程提升当前执行程序的优先级,使得低于当前优先级的中断暂时得不到响应。适当时候放弃优先级升级功能,恢复原状。
可能有人知道,还有个可以关闭或屏蔽优先级高至-1级的HardFault异常的控制寄存器,就是FAULTMASK,也是1位有效位,操作跟PRIMASK类似。有兴趣的话,可以自行进一步研究下。
审核编辑:汤梓红
-
ARM
+关注
关注
134文章
9036浏览量
366651 -
寄存器
+关注
关注
31文章
5308浏览量
119936 -
STM32
+关注
关注
2265文章
10860浏览量
354574 -
中断
+关注
关注
5文章
895浏览量
41368 -
stm32cubemx
+关注
关注
5文章
280浏览量
14739
原文标题:为何修改BASEPRI寄存器无效?
文章出处:【微信号:stmcu832,微信公众号:茶话MCU】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论