riscv中gd32vf103的中断行为分析

从riscv底层原理分析gd32vf103的中断行为

1.概述

2.中断向量表初始化

3.详细分析一下irq_entry

4.关于gd32vf103中断编程模型的理解

1.概述在处理riscv处理器中断的时候，需要弄清楚两个概念：

1.向量中断

2.非向量中断

对于向量中断，其中断发生后，pc指针会根据中断的类型跳转到基地址+中断号*4的地址处去执行中断处理程序，做过stm32的，应该比较清楚向量中断的大概样子。当然，riscv也是支持这种向量中断，这样每个地址处会安排一个特定的中断处理函数，当中断发生后，跳转到特定的函数去执行即可。

对于非向量中断，则表示中断发生后只有一个入口，需要在这一个中断中去判断具体中断号，这种行为可以在常见的mips处理器、sparc处理器中看到。

既然riscv支持这两种中断处理方式，正好gd32vf103的库函数也实现了这两种机制，那么就彻底的分析一下实现的策略。

2.中断向量表初始化任何代码在最初的汇编级别的初始化时，都会指定向量的基地址。当然riscv也不例外。

对于向量中断来说

/*

* Intialize ECLIC vector interrupt

* base address mtvt to vector_base

*/

la t0， vector_base

csrw CSR_MTVT， t0

这里的理解就向mtvt寄存器中存放vector_base，该处存放向量地址入口，每个向量中断发生，则根据偏移执行对应的函数。

.globl vector_base

.type vector_base， @object

vector_base：

#if defined（DOWNLOAD_MODE） && （DOWNLOAD_MODE ！= DOWNLOAD_MODE_FLASH）

j _start /* 0： Reserved， Jump to _start when reset for ILM/FlashXIP mode.*/

.align LOG_REGBYTES /* Need to align 4 byte for RV32， 8 Byte for RV64 */

#else

DECLARE_INT_HANDLER default_intexc_handler /* 0： Reserved， default handler for Flash download mode */

#endif

DECLARE_INT_HANDLER default_intexc_handler /* 1： Reserved */

DECLARE_INT_HANDLER default_intexc_handler /* 2： Reserved */

DECLARE_INT_HANDLER eclic_msip_handler /* 3： Machine software interrupt */

DECLARE_INT_HANDLER default_intexc_handler /* 4： Reserved */

DECLARE_INT_HANDLER default_intexc_handler /* 5： Reserved */

。

。

。

对于向量函数的处理，不用过多介绍。

下面非向量中断的入口

/*

* Set ECLIC non-vector entry to be controlled

* by mtvt2 CSR register.

* Intialize ECLIC non-vector interrupt

* base address mtvt2 to irq_entry.

*/

la t0， irq_entry

csrw CSR_MTVT2， t0

csrs CSR_MTVT2， 0x1

其中irq_entry表示了非向量的处理过程。csrs CSR_MTVT2， 0x1该指令的解析如下：

mtvt2［0］ = 1 mtvt2［0］为0时，中断入口使用mtvec寄存器，mtvt2［0］为1时，中断入口为mtvt2［31:2］。

3.详细分析一下irq_entry分析非向量中断的行为，可以更好的理解riscv的中断底层的处理机制。

.global irq_entry

/* This label will be set to MTVT2 register */

irq_entry：

/* Save the caller saving registers （context） */

SAVE_CONTEXT

/* Save the necessary CSR registers */

SAVE_CSR_CONTEXT

/* This special CSR read/write operation， which is actually

* claim the CLIC to find its pending highest ID， if the ID

* is not 0， then automatically enable the mstatus.MIE， and

* jump to its vector-entry-label， and update the link register

*/

csrrw ra， CSR_JALMNXTI， ra

/* Critical section with interrupts disabled */

DISABLE_MIE

/* Restore the necessary CSR registers */

RESTORE_CSR_CONTEXT

/* Restore the caller saving registers （context） */

RESTORE_CONTEXT

/* Return to regular code */

mret

从中断处理的原理上来讲，中断处理分三部分：

1.保存当前现场

2.进入中断处理函数

3.恢复现场

其中SAVE_CONTEXT确实是保存上下文现场的方式。

.macro SAVE_CONTEXT

csrrw sp， CSR_MSCRATCHCSWL， sp

/* Allocate stack space for context saving */

#ifndef __riscv_32e

addi sp， sp， -20*REGBYTES

#else

addi sp， sp， -14*REGBYTES

#endif /* __riscv_32e */

STORE x1， 0*REGBYTES（sp）

STORE x4， 1*REGBYTES（sp）

STORE x5， 2*REGBYTES（sp）

STORE x6， 3*REGBYTES（sp）

STORE x7， 4*REGBYTES（sp）

STORE x10， 5*REGBYTES（sp）

STORE x11， 6*REGBYTES（sp）

STORE x12， 7*REGBYTES（sp）

STORE x13， 8*REGBYTES（sp）

STORE x14， 9*REGBYTES（sp）

STORE x15， 10*REGBYTES（sp）

#ifndef __riscv_32e

STORE x16， 14*REGBYTES（sp）

STORE x17， 15*REGBYTES（sp）

STORE x28， 16*REGBYTES（sp）

STORE x29， 17*REGBYTES（sp）

STORE x30， 18*REGBYTES（sp）

STORE x31， 19*REGBYTES（sp）

#endif /* __riscv_32e */

.endm

按照riscv的数据模型，又分为I数据模型和E数据模型，这部分在riscv的MISA寄存器中有描述。简而言之，E数据模型会比I数据模型少一半的寄存器，E数据模型是专门针对嵌入式应用场景的，更少的寄存器意味着更快速的压栈和出栈，实时性相应会更加优秀。

I数据模型一共有32个寄存器，而E数据模型是16个寄存器。

所以在进行中断入栈的时候，E数据模型会压入10个寄存器。

caller代表中断上层函数可以使用的寄存器，所以

x1，x5，x6，x7，x10，x11，x12，x13，x14，x15

这10个寄存器会保存，上述程序多保存了x4。

下面理解一下中断的处理，通过csrrw ra， CSR_JALMNXTI， ra该指令进行分析。

不难发现，这个是个芯来自定义扩展指令，CSR_JALMNXTI寄存器通过gdb解析可以看到如下的数据

其中0x7ed则是该寄存器的地址。

那么一条指令是如何实现中断的处理的呢？

实际上该指令首先会判断当前eclic中是否有挂起未处理的中断，如果没有，那这条指令向下执行，并不会处理任何事情，一旦存在，那么会跳转到eclic的中断向量的入口，这里便是关键的地方了。

另外需要注意的是，默认进入中断时，保存现场时，此处是关闭中断的，当执行这条语句，中断便会开启，然后判断是否还有中断未响应，这样可以达到中断咬尾的效果。

并且当中断处理函数执行完成后，又会回到该指令执行一次，判断是否还需要处理中断。这一切的行为都是由硬件完成，大大提高中断处理的效率。

现场恢复则是中断处理的逆过程，这里不赘述。

4.关于gd32vf103中断编程模型的理解对于cortex-m3等处理器来说，riscv的底层模型似乎更加复杂一些，但是实际上弄清楚riscv中断处理模型，eclic中断处理机制，以及向量中断，非向量中断和一条中断处理指令csrrw ra， CSR_JALMNXTI， ra后，也不会觉得十分的难以理解。

玩gd32vf103，其riscv底层汇编级别的中断处理一般都不会太多需要修改的，理解就可以。需要使用好的是eclic配置，还有相关的gpio的中断引脚的配置即可。将中断线、eclic配置完成，具体中断处理函数中实现自己的业务逻辑即可，不需要有许多学习成本。

原文标题：从riscv底层原理分析gd32vf103的中断行为

文章出处：【微信公众号：嵌入式IoT】欢迎添加关注！文章转载请注明出处。

责任编辑：haq