异常

针对类似严重异常情况的原因我在这里大致总结下,与大家分享。

1、时钟问题。一般表现在时钟配置异常,比方配置超出芯片主频工作范围。【对于STM32系列MCU,如果使用STM32CUBEMX图形化工具做配置,基本可以回避这个问题】

2、电源问题。比方电源质量差,纹波过大,尤其开关电源供电时;或者供电芯片质量差,输出不稳定;或者系统供电能力不足而引起电源波动等。

3、BOOT脚配置问题。对于ARM芯片往往都有些BOOT配置脚。经常遇到有人因为BOOT脚的焊接或接触不良导致各类奇怪问题。这种情况多表现在芯片功能时好时坏,或者部分芯片正常,部分芯片异常。

4、启动文件问题。经常因为选错了启动文件,导致程序无法正常运行,或者说调试时好好的,脱机运行就出鬼。这点在做不同系列芯片间移植时最容易碰到。

5、中断请求位清除问题。由于中断请求位没有及时清除导致中断没完没了的重复进入,感觉系统死机一般。

6、堆或栈的越界溢出。这个也会导致芯片无法正常工作,调试时往往可能会有硬错提示。

7、VCAP脚问题。有些MCU芯片有VCAP脚,该类脚往往需要接上适当的电容,如果无视了它的话,也可能导致整个芯片的功能异常。

上面这几个原因比较容易导致MCU出现功能严重异常,也不太容易简单地通过查看MCU技术手册直接获得答案,分享出来算作一些提醒。

来源:网络

围观 446

在ARM体系中,通常有以下3种方式控制程序的执行流程:

• 在正常程序执行过程中,每执行一条ARM指令,程序计数器寄存器(PC)的值加4个字节;每执行一条Thumb指令,程序计数器寄存器(PC)的值加2个字节。整个过程是顺序执行。

• 通过跳转指令,程序可以跳转到特定的地址标号处执行,或者跳转到特定的子程序处执行。其中,B指令用于执行跳转操作;BL指令在执行跳转操作的同时,保存子程序的返回地址;BX指令在执行跳转操作的同时,根据目标地址的最低位可以将程序状态切换到Thumb状态;BLX指令执行3个操作:跳转到目标地址处执行,保存了子程序的返回地址,根据目标地址的最低位可以将程序状态切换到Thumb状态。

• 当异常中断发生时,系统执行完当前指令后,将跳转到相应的异常中断处理程序处执行。在当异常中断处理程序执行完成后,程序返回到发生中断的指令的下一条指令处执行。在进入异常中断处理程序时,要保存被中断的程序的执行现场,在从异常中断处理程序退出时,要恢复被中断的程序的执行现场。

ARM体系中异常中断种类:

• 复位(Reset):当处理器的复位引脚有效时,系统产生复位异常中断,程序跳转到复位异常中断处理程序处执行。复位异常中断通常用在下面两种情况:系统加电时和系统复位时。跳转到复位中断向量处执行,称为软复位。

• 未定义指令(Undefined Instruction):当ARM处理器或者是系统中的协处理器认为当前指令未定义时,产生未定义的指令异常中断。

• 软件中断(Software Interrupt SWI):这是一个由用户定义的中断指令。可用于用户模式下的程序调用特权操作指令。在实时操作系统中可以通过该机制实现系统功能调用。

• 指令预取中止(Prefetch Abort):如果处理器预取的指令的地址不存在,或者该地址不允许当前指令访问,当该被预取的指令执行时,处理器产生指令预取中止异常中断。

• 数据访问中止(Data Abort):如果数据访问指令的目标地址不存在,或者该地址不允许当前指令访问,处理器产生数据访问中止异常中断。

• 外部中断请求(IRQ):当处理器的外部中断请求引脚有效,而且CPSR寄存器的I控制位被清除时,处理器产生外部中断请求(IRQ)异常中断。系统中各外设通常通过该异常中断请求处理器服务。

• 快速中断请求(FIQ):当处理器的外部快速中断请求引脚有效,而且CPSR寄存器的F控制位被清除时,处理器产生外部中断请求(FIQ)异常中断。

对异常中断的响应过程(这几点都是ARM核自己已经完成的动作):

• 保存处理器当前状态、中断屏蔽位以及各条件标志为。这是通过将当前程序状态寄存器CPSR的内容保存到将要执行的异常中断对应的SPSR寄存器中实现的。各异常中断有自己的物理SPSR寄存器。

• 设置当前程序状态寄存器CPSR中相应的为。包括:设置CPSR中的位,使处理器进入当前相应的执行模式(处理器模式);设置CPSR中的位,禁止IRQ中断,当进入FIQ模式时,禁止FIQ中断。

• 将寄存器lr_mode设置成返回地址。

• 将程序计数器值(PC),设置成该异常中断的中断向量地址,从而跳转到相应的异常中断处理程序处执行。

从异常中断处理程序中返回(这些返回动作是需要自己写代码完成的):

• 恢复被中断的程序的处理器状态,即将SPSR_mode寄存器内容复制到CPSR中。

• 返回到发生异常中断的指令的下一条指令执行,即将lr_mode寄存器的内容复制到程序计算器PC中。

复位异常中断处理程序不需要返回。在复位异常中断处理程序开始整个用户程序的执行,因而它不需要返回。

转自: uTank

围观 485

ARM中有5种异常模式,有7种中断源。这7种中断源中有些中断是我们希望发生的,但有些中断是我们不希望发生的。

我们希望发生的中断:

软中断:属于svc模式,通过SWI指令便可以产生软中断,进入到svc模式。

irq中断:属于irq模式,当产生普通的外部中断时,处理器便进入到IRQ模式。

fiq中断:属于fiq模式,当产生高优先级外部中断时,处理器便进入到FIQ模式。

我们不希望发生的中断:

复位:属于svc模式,当系统上电时便会产生复位中断,系统进入到svc模式。复位中断不需要中断返回。

取指中止中断:属于abt模式,当预取指发生错误时,便产生取指中止中断,进入到abt模式。

数据中止中断:属于abt模式,当访问数据存储器时,便产生数据中止中断,进入到abt模式。

未定义指令中断:属于und模式,当执行到一条未定义指令时,便产生未定义指令中断,系统进入到und模式。

中断的优先级:

ARM中有6个优先级。各个中断的优先级顺序如下:(1 6 6s 5 2 4 3)

复位: 1
数据中止中断:2
fiq中断:3
irq中断:4
预取址中止中断:5
未定义指令中断和软中断:6

关于各种中断在中断返回时还需要给LR减去一个不同的偏移量的问题我觉得没必要深入研究了,这还要涉及到ARM指令的流水线技术,平时写中断代码都是用C写的,没必要知道这个。用到时再去查表即可。

ARM中的异常和中断

处理器在进入异常和退出异常时所做的工作:

进入异常时:

1、将要返回处的地址保存在对应异常模式的LR中。(复位不需要保存返回地址)
2、将cpsr的内容复制到对应异常模式的spsr中。
3、强制修改cpsr的内容,进入到相应异常模式以及根据需要修改某些位。
4、强制PC从相应的中断向量地址处进行取址。

注:以上这些步骤都是有cpu自动完成的,也就是当有中断产生时,硬件就会自动完成上述步骤。

退出异常时:

1、将LR中保存的地址赋给PC。
2、将spsr的内容恢复给cpsr。
3、将irq中断禁止位清零。

注:只需要在异常处理程序中写一句返回指令(如上面的表4.1所示)即可全部实现上述的步骤。

转自: frank_yxs

围观 474

我们在从事MCU应用开发过程中,难免会碰到MCU芯片异常的问题。比如异常复位,表现为复位脚有电平跳变或者干脆处于复位电平;在做代码调试跟踪时,发现代码往往进不到用户main()程序;或者时不时感觉芯片死掉了,功能完全不可控等。

针对类似严重异常情况的原因我在这里大致总结下,与大家分享。

1、时钟问题。一般表现在时钟配置异常,比方配置超出芯片主频工作范围。【对于STM32系列MCU,如果使用STM32CUBEMX图形化工具做配置,基本可以回避这个问题】

2、电源问题。比方电源质量差,纹波过大,尤其开关电源供电时;或者供电芯片质量差,输出不稳定;或者系统供电能力不足而引起电源波动等。

3、BOOT脚配置问题。对于ARM芯片往往都有些BOOT配置脚。经常遇到有人因为BOOT脚的焊接或接触不良导致各类奇怪问题。这种情况多表现在芯片功能时好时坏,或者部分芯片正常,部分芯片异常。

4、启动文件问题。经常因为选错了启动文件,导致程序无法正常运行,或者说调试时好好的,脱机运行就出鬼。这点在做不同系列芯片间移植时最容易碰到。

5、中断请求位清除问题。由于中断请求位没有及时清除导致中断没完没了的重复进入,感觉系统死机一般。

6、堆或栈的越界溢出。这个也会导致芯片无法正常工作,调试时往往可能会有硬错提示。

7、VCAP脚问题。有些MCU芯片有VCAP脚,该类脚往往需要接上适当的电容,如果无视了它的话,也可能导致整个芯片的功能异常。

上面这几个原因比较容易导致MCU出现功能严重异常,也不太容易简单地通过查看MCU技术手册直接获得答案,分享出来算作一些提醒。

来源:网络

围观 407

近来翻了翻uC/OS-II官网给出来的ARM7-ARM9移植手册(AN-104),分析了在ARM中移植的问题,想想从来没有认真的学习过ARM的汇编,趁着这个机会复习复习吧。其实底层的东西才是创造力的心脏。

其中的移植代码中存在的很多问题比如中断的关闭和开启,任务级别的情景切换,中断到任务的情景切换都是我们在平时移植中讲到,我也不在此强调了。在官网中提供的移植过程中存在异常处理机制,这个本不是在移植过程中考虑的,但是文档中确实提供了一个比较好的处理方式。我在此对这一段时间的学习做一个总结。

首先需要了解ARM的异常处理机制,异常是每一种处理器都必须考虑的问题之一,关键在于如何让处理,返回地址在什么位置都是需要考虑的,ARM中支持7种异常,其中包括复位、未定义指令异常、软中断异常、预取指令中止、数据中止、IRQ、IFQ。每一种异常运行在特定的处理器模式下。我在此逐一的分析。

一般异常发生后,CPU都会进行一系列的操作,这些操作有一部分是CPU自动完成,有一部分是需要我们程序员完成。

首先说明CPU会自动完成的部分,用ARM结构手册中的代码描述如下:

R14_ = return link //这个可以参看寄存器的说明,两个作用
SPSR_< exception_mode > = CPSR
CPSR[4:0] = exception mode number
CPSR[5] = 0 ; //AEM指令
If ==Reset or Fiq then //只有在复位和FIQ模式下才会关闭FIQ中断
CPSR[6] = 1 ;
CPSR[7] = 1 ; //任何异常模式下都会关闭IRQ中断
PC = exception vector address

从上面的代码中我们可以发现CPU自动处理的过程包括如下:

1、拷贝CPSR到SPSR_

2、设置适当的CPSR位: 改变处理器状态进入ARM状态;改变处理器模式进入相应的异常模式;设置中断禁止位禁止相应中断。

3、更新LR_,这个寄存器中保存的是异常返回时的链接地址

4、设置PC到相应的异常向量

以上的操作都是CPU自动完成,异常的向量表如下:

返回地址问题

异常的返回地址也是需要我们注意的地方,不同的异常模式返回地址也是存在差异的,这主要是因为各种异常产生的机理存在差别所导致的。这样我们的需要在异常进入处理函数之前或者在返回时调整返回地址,一般采用进入异常处理函数前进行手动调整。下面每一种异常R14保存的值都给了出来,其中也包含了CPU自动处理的部分,根据保存的R14就可以知道怎样实现地址的返回。

复位异常:

可以看出该模式下的先对来说返回地址也比较简单,不需要做太多的描述。

未定义的指令异常:

返回的方式也比较简单:

MOVS PC, R14

软中断异常:

返回的方式也比较简单:

MOVS PC, R14

预取指令中止异常:

返回需要做下面的调整:

SUBS PC, R14, #4

数据中止

返回地址需要做下面的调整:

如果需要重新访问数据则:

SUBS PC, R14, #8

如果不需要重新访问数据则:

SUBS PC, R14, #4

IRQ中断的处理过程:

返回地址需要做下面的调整:

SUBS PC,R14,#4

IFQ中断:

返回地址需要做下面的调整:

SUBS PC, R14 ,#4

从上面的代码可以知道,对于每一种异常,保存的返回地址都是不一样的,一般都需要我们手动的跳转,当然调整的时机也需要我们选择,是在进入处理前跳转还是返回时调整都是需要我们程序员控制的。

在ARM Developer Suite Developer Guide中对ARM处理器的异常处理操作提供能更加详细的解释,每一种异常下的处理方式如下文描述:

异常返回时另一个非常重要的问题是返回地址的确定,在前面曾提到进入异常时处理器会有一个保存LR 的动作,但是该保存值并不一定是正确的返回地址,下面以一个简单的指令执行流水状态图来对此加以说明。

我们知道在ARM 架构里,PC值指向当前执行指令的地址加8处,也就是说, 当执行指令A(地址0x8000)时,PC 等于指令C 的地址(0x8008)。假如指令A 是“BL”指令,则当执行该指令时,会把PC(=0x8008)保存到LR 寄存器里面,但是接下去处理器会马上对LR 进行一个自动的调整动作:LR=LR-0x4。这样,最终保存在 LR 里面的是 B 指令的地址,所以当从 BL 返回时,LR 里面正好是正确的返回地址。同样的调整机制在所有LR自动保存操作中都存在,比如进入中断响应时,处理器所做的LR 保存中,也进行了一次自动调整,并且调整动作都是LR=LR-0x4。

下面,我们对不同类型的异常的返回地址依次进行说明:

假设在指令A 处(地址0x8000)发生了异常,进入异常响应后,LR 上经过调整保存的地址值应该是B 的地址0x8004。

1、如果发生的是软件中断,即A 是“SWI”指令

异常是由指令本身引起的,从 SWI 中断返回后下一条执行指令就是B,正好是LR 寄存器保存的地址, 所以只要直接把LR 恢复给PC。

MOVS pc, lr

2、发生的是Undefined instruction异常

异常是由指令本身引起的,从异常返回后下一条执行指令就是B,正好是LR 寄存器保存的地址, 所以只要直接把LR 恢复给PC。

MOVS pc, lr

3、发生的是IRQ或FIQ中断

因为指令不可能被中断打断,所以A指令执行完以后才能响应中断,此时PC已更新,指向指令D的地址(地址0x800C),LR 上经过调整保存的地址值是C 的地址0x8008。中断返回后应该执行B指令,所以返回操作是:

SUBS pc, lr, #4

4、发生的是Prefetch Abort异常

该异常并不是处理器试图从一个非法地址取指令时触发,取出的指令只是被标记为非法,按正常处理流程放在流水线上,在执行阶段触发Prefetch Abort异常,此时LR 上经过调整保存的地址值是B 的地址0x8004。异常返回应该返回到A指令,尝试重新取指令,所以返回操作是:

SUBS pc, lr, #4

5、发生的是“Data Abort”

CPU访问存储器时触发该异常,此时PC指向指令D的地址(地址0x800C),LR 上经过调整保存的地址值是C 的地址0x8008。异常返回后,应回到指令A,尝试重新操作存储器,所以返回操作是:

SUBS pc, lr, #8

以上就是ARM异常的CPU操作部分,接下来就是程序员应该完成的操作。

1. 由于CPU会自动跳转到对应的异常向量中,因此只需要在在各个异常向量中存放对应的操作,最简单的都是存放一个B指令跳转到对应的异常处理函数的操作即可。但由于B指令的跳转返回只有+-32M,而异常处理函数的地址可能会超过+-32M,因此可以采用另一种方式实现方式:在异常向量中保存一条指令LDR PC [addr],其中的addr中就保存了异常处理函数的地址,当然addr的相对地址要小于+-32M。这样也就解决了跳转范围的问题。

2. 接下来就是异常处理函数对应的操作,可以在进入异常处理之前就进行返回地址的调整,这样后面就不用进行处理啦,当然也可以在返回过程中再调整。一般都是在这个过程中进行调整。进行压栈操作,保存对应的环境变量。调用实际的处理过程等。

3. 出栈,恢复CPU的状态和寄存器的值。由于第一步中已经调整好返回地址,这一步不需要再次调整。当然如果之前没有调整,这里则需要进行相应的调整。

在uC/OS-II的官网移植中采用通用异常处理函数的方式实现异常的处理,下面我们来分析其中的部分代码:

首先是处理器部分的移植,包括异常向量、异常的ID号,存储异常处理函数地址的地址等:

/*ARM的异常ID号,支持7种类型的异常,每一种异常都存在一个ID号*/
#define OS_CPU_ARM_EXCEPT_RESET 0x00
#define OS_CPU_ARM_EXCEPT_UNDEF_INSTR 0x01
#define OS_CPU_ARM_EXCEPT_SWI 0x02
#define OS_CPU_ARM_EXCEPT_PREFETCH_ABORT 0x03
#define OS_CPU_ARM_EXCEPT_DATA_ABORT 0x04
#define OS_CPU_ARM_EXCEPT_ADDR_ABORT 0x05
#define OS_CPU_ARM_EXCEPT_IRQ 0x06
#define OS_CPU_ARM_EXCEPT_FIQ 0x07
#define OS_CPU_ARM_EXCEPT_NBR 0x08
/*异常向量地址*/
#define OS_CPU_ARM_EXCEPT_RESET_VECT_ADDR (OS_CPU_ARM_EXCEPT_RESET * 0x04 + 0x00) //0x00
#define OS_CPU_ARM_EXCEPT_UNDEF_INSTR_VECT_ADDR (OS_CPU_ARM_EXCEPT_UNDEF_INSTR * 0x04 + 0x00) //0x04
#define OS_CPU_ARM_EXCEPT_SWI_VECT_ADDR (OS_CPU_ARM_EXCEPT_SWI * 0x04 + 0x00) //0x08
#define OS_CPU_ARM_EXCEPT_PREFETCH_ABORT_VECT_ADDR (OS_CPU_ARM_EXCEPT_PREFETCH_ABORT * 0x04 + 0x00) //0x0c
#define OS_CPU_ARM_EXCEPT_DATA_ABORT_VECT_ADDR (OS_CPU_ARM_EXCEPT_DATA_ABORT * 0x04 + 0x00) //0x10
/*这个异常是ARM中不支持的异常*/
#define OS_CPU_ARM_EXCEPT_ADDR_ABORT_VECT_ADDR (OS_CPU_ARM_EXCEPT_ADDR_ABORT * 0x04 + 0x00) //0x14
#define OS_CPU_ARM_EXCEPT_IRQ_VECT_ADDR (OS_CPU_ARM_EXCEPT_IRQ * 0x04 + 0x00) //0x18
#define OS_CPU_ARM_EXCEPT_FIQ_VECT_ADDR (OS_CPU_ARM_EXCEPT_FIQ * 0x04 + 0x00) //0x1c
/*存储异常处理函数地址的地址*/
/* ARM exception handlers addresses */
#define OS_CPU_ARM_EXCEPT_RESET_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_RESET * 0x04 + 0x20) //0x20
#define OS_CPU_ARM_EXCEPT_UNDEF_INSTR_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_UNDEF_INSTR * 0x04 + 0x20) //0x24
#define OS_CPU_ARM_EXCEPT_SWI_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_SWI * 0x04 + 0x20) //0x28
#define OS_CPU_ARM_EXCEPT_PREFETCH_ABORT_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_PREFETCH_ABORT * 0x04 + 0x20) //0x2c
#define OS_CPU_ARM_EXCEPT_DATA_ABORT_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_DATA_ABORT * 0x04 + 0x20) //0x30
#define OS_CPU_ARM_EXCEPT_ADDR_ABORT_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_ADDR_ABORT * 0x04 + 0x20) //0x34
#define OS_CPU_ARM_EXCEPT_IRQ_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_IRQ * 0x04 + 0x20) //0x38
#define OS_CPU_ARM_EXCEPT_FIQ_HANDLER_ADDR (OS_CPU_ARM_EXCEPT_FIQ * 0x04 + 0x20) //0x3c
/*存储在异常向量中的内容,实质上是LDR PC,[PC,#0x18]的机器码*/
#define OS_CPU_ARM_INSTR_JUMP_TO_SELF 0xEAFFFFFE
/* ARM "Jump To Exception Handler" asm instruction */
#define OS_CPU_ARM_INSTR_JUMP_TO_HANDLER 0xE59FF018

异常的初始化函数,首先,完成了在异常向量中存储指令的操作,采用机器码的形式就能避免直接访问寄存器什么的,其次,完成在固定的地址处存放对应异常处理函数的地址。其中采用了赋值的形式也是需要注意的,采用的强制类型转换和指针相结合的形式。保证了是修改地址处的内容。而不是修改地址。

/*初始化异常中断向量*/
void OS_CPU_InitExceptVect (void)
{
/*
OS_CPU_ARM_EXCEPT_UNDEF_INSTR_VECT_ADDR是对应中断向量表的地址
OS_CPU_ARM_INSTR_JUMP_TO_HANDLER是保存了对应的OS_CPU_ARM_INSTR_JUMP_TO_HANDLER(实质上是一个指令)

实质上就是在异常向量中存放了:LDR PC [PC, #0x18],也就是让PC指向对应的异常处理地址中的内容,

也就是实现到实际处理函数的跳转。

异常处理地址中存储了实际的异常处理函数的地址

其他的异常也有相同的操作,OS_CPU_ARM_INSTR_JUMP_TO_HANDLER是一个指令的机器码形式
*/
(*(INT32U *)OS_CPU_ARM_EXCEPT_UNDEF_INSTR_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_UNDEF_INSTR_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptUndefInstrHndlr;

(*(INT32U *)OS_CPU_ARM_EXCEPT_SWI_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_SWI_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptSwiHndlr;

(*(INT32U *)OS_CPU_ARM_EXCEPT_PREFETCH_ABORT_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_PREFETCH_ABORT_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptPrefetchAbortHndlr;

(*(INT32U *)OS_CPU_ARM_EXCEPT_DATA_ABORT_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_DATA_ABORT_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptDataAbortHndlr;

(*(INT32U *)OS_CPU_ARM_EXCEPT_ADDR_ABORT_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_ADDR_ABORT_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptAddrAbortHndlr;

(*(INT32U *)OS_CPU_ARM_EXCEPT_IRQ_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_IRQ_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptIrqHndlr;

/*在异常向量中存储对应的操作,实质上就是将PC值调转*/
(*(INT32U *)OS_CPU_ARM_EXCEPT_FIQ_VECT_ADDR) = OS_CPU_ARM_INSTR_JUMP_TO_HANDLER;
(*(INT32U *)OS_CPU_ARM_EXCEPT_FIQ_HANDLER_ADDR) = (INT32U)OS_CPU_ARM_ExceptFiqHndlr;
}

有必要的讨论一下,为什么在向量中存储的是指令: LDR PC,[PC,#0x18],我们从上面的地址可以知道,IRQ异常处理函数地址被存储到了0x00000038中,异常向量与该地址之间的差值是0x20,那么为什么在其中存储的值只是0x18呢?这还要讨论ARM的流水线结构,当前执行的命令相比PC指向的地址差0x08。也就是当前执行的指令的地址是PC-0x08.当PC指向异常向量以后(取值),还需要等待一个时钟(译码)之后才会被执行(真正意义上的执行操作),而这时PC值已经被更新了。指向了Vector+0x8的位置,因此我们可以知道,当执行向量中的代码时,这时PC=Vector+0x8,而这时相对于固定的0x20-0x08=0x18,这也就是为什么是LDR PC,[PC,#0x18],而不是LDR PC,[PC,#0x20].

采用上面的例子说明IRQ的向量为0x00000018,而设定好的固定地址用来存储对应异常处理函数地址的地址是0x00000038,当CPU执行完PC = 0x00000018以后,还需要译码、才能被执行,这时候PC值已经更新为PC = 0x00000018 + 0x08;这时候固定地址距离PC的相对位置位0x00000038 – PC = 0x18,而该地址中保存了IRQ中断的通用处理函数OS_CPU_ARM_ExceptIrqHndlr()的地址,LDR PC,[PC,#0x18]这条指令是指将PC+0x18地址处的内容加载到PC中,实质上也就完成跳转到异常处理函数的操作。

这样处理的好处是因为LDR的加载范围是一个固定值+-32M,我们不能保证异常处理程序的地址刚好在+-32M左右,采用这种LDR PC, ADDR(固定地址)的形式就能实现大范围的跳转操作。

我们仅仅以FIQ中断处理的形式进行讨论,其他的异常有一定的相似性,只是在返回地址上存在差别。这段代码主要是完成寄存器的压栈,返回地址的调整,保存等操作。具体的看下面的分析:

AREA CODE, CODE, READONLY
CODE32
OS_CPU_ARM_ExceptFiqHndlr
;修改中断返回地址,这属于进入真正处理函数前的返回地址调整,具体的返回地址依据前面保存的R14进行相应的修改。
SUB LR, LR, #4 ; LR offset to return from this exception: -4.
;压栈操作
STMFD SP!, {R0-R12, LR} ; Push working registers.
;保存链接寄存器
MOV R2, LR ; Save link register.
;设置好ID号,这是非常必要的,只有这样才能辨别属于那种异常
MOV R0, #OS_CPU_ARM_EXCEPT_FIQ ; Set exception ID
/*跳转到通用的异常处理函数,传递的参数是异常ID号*/
B OS_CPU_ARM_ExceptHndlr ; Branch to global exception handler.

OS_CPU_ARM_ExceptHndlr(except_type)是一个通用的异常处理函数,可以对除了IRQ以外的其他异常进行控制操作。在这个通用处理函数中又调用了下面的函数OS_CPU_ARM_ExceptHndlr_BreakExcept()或者OS_CPU_ARM_ExceptHndlr_BreakTask()。这两个函数中又调用了通用处理函数OS_CPU_ExceptHndlr(),然后OS_CPU_ExceptHndlr()中调用具体的中断处理操作。

一般的OS_CPU_ExceptHndlr()处理形式,可以认为是一个模板如下:

void OS_CPU_ExceptHndlr (INT32U except_type)
{
/* Determine behavior according to exception type (except_type) */
/* If an IRQ or FIQ ,具体的可能要使用中断向量等形式实现*/
while (there are interrupting devices) {
/* Clear interrupting device */
OS_CPU_SR_INT_En(); /* Enable nesting, if desired */
/* Handle interrupt */
}
}

这是其中的一段关于IRQ中断的文字复述:

IRQ中断的基本的流程图如下:

以上的uC/OS-II异常处理就分析完了,这种方式的实现实质上是采用了通用模板的形式,这样实现出来的形式只需要控制一定的,具体的一些IRQ中断处理函数(如定时器,GPIO等的中断),与具体的厂商有很大的关系,有的厂商采用硬件寄存器的方式进行设计,有的采用软件方式实现,因此具体的中断。

后面我再分析我们通常认为的中断(实质上就是IRQ和IFQ中某一个具体中断)处理方式。

文章来源:博客园

围观 593
订阅 RSS - 异常