MIPS32裸机系统异常：中断触发BEV处理函数而非指定向量

核心矛盾点 #

从你提供的CP0寄存器状态来看，存在三个关键矛盾：

1. 配置中已清除BEV位，但中断发生时却进入了BEV模式下的通用异常向量0x80000380；
2. STATUS寄存器的EXL位为1（0x00000303的bit1是1），但配置代码已清除该位；
3. STATUS的IM字段全为0，理论上不会响应中断，但CAUSE寄存器显示有中断请求。

具体原因拆解 #

1. EXL位为1导致中断走通用异常路径 #

根据MIPS32 ISA规范，当STATUS寄存器的EXL位（bit1）为1时，CPU处于异常级别，此时所有后续异常（包括中断）都会强制跳转到通用异常向量，而非IV位指定的中断专用向量。

你的配置代码虽然清除了EXL位，但在配置完成到使能中断的这段时间里，可能发生了未被捕获的异常（比如总线错误、非法指令、地址对齐错误等），导致EXL位被重新置位。此时CPU无法进入预期的0x80000200中断向量。

2. BEV位实际未被清除（或被后续修改） #

0x80000380是BEV=1时的通用异常向量地址，这说明中断发生时BEV位实际为1，与你读取的STATUS值矛盾。可能的原因：

• 宏定义错误：检查CP0_STATUS_BEV的定义是否为(1 << 22)（MIPS32中BEV是STATUS寄存器的bit22），如果宏定义错误，清除BEV位的操作会完全失效；
• 后续代码篡改：配置代码执行后，其他模块的代码可能重新写了STATUS寄存器，置位了BEV；
• 读取时机偏差：你读取STATUS时，CPU可能已经退出异常状态，BEV位被临时修改后恢复，导致读取值与异常发生时的实际状态不符。

3. 中断屏蔽位IM未正确配置 #

STATUS寄存器的IM字段（bit8~bit15）是中断屏蔽位，只有对应位为1时，CPU才会响应该级别的中断。你的STATUS值0x00000303中IM字段全为0，理论上不会响应任何中断，但CAUSE寄存器的IP字段（0x81）显示有中断请求，说明要么：

• 你在使能中断时未正确设置IM位；
• 后续代码修改了IM位，但修改过程中触发了异常。

解决步骤 #

1. 定位EXL位被置位的根源：

   • 在配置代码执行后、使能中断前添加JTAG断点，检查STATUS的EXL位是否保持为0；
   • 若EXL位被置位，读取CAUSE寄存器的EXCCODE字段（bit2~bit6），定位之前发生的异常类型，针对性修复。

2. 验证BEV位的真实状态：

   • 通过JTAG实时捕获异常发生瞬间的STATUS寄存器值，确认BEV位是否为1；
   • 核对CP0_STATUS_BEV宏定义，确保清除BEV位的代码regval &= ~CP0_STATUS_BEV能正确修改bit22。

3. 正确配置中断屏蔽位：

   • 使能中断时，需同时设置STATUS的IM字段，比如要响应第0级中断，需执行：

     regval = cp0_getstatus();
     regval |= (1 << 8); // 置位IM0位（bit8）
     cp0_putstatus(regval);
     

4. 确认向量段的链接有效性：

   • 查看System.map中0x80000180和0x80000200地址对应的符号，确认处理代码已正确链接到指定位置；
   • 检查0x80000380处的_bev_exception是否是因为未定义向量的默认跳转导致，确保向量段的内存权限可执行。

内容的提问来源于stack exchange，提问作者wangt13