RT-Thread中断嵌套问题分析与解决

1. 问题现象与初步分析

在RK3506平台上进行AMP核间通信测试时，RTT（RT-Thread）端出现了一个棘手的错误：

code复制Function[rt_mq_recv] shall not be used in ISR
(0) assertion failed at function:rt_mq_recv, line number:3085

这个错误表明系统错误地认为当前线程处于中断服务例程（ISR）中，而实际上我们是在正常的线程上下文中调用rt_mq_recv函数。让我们先看看出问题的代码段：

c复制ret = rpmsg_queue_recv(info->instance, remote_queue, 
                       (uint32_t *)&master_ept_id, 
                       g_rx_buffer, 
                       sizeof(g_rx_buffer), 
                       &msg_len, 
                       RL_BLOCK);
if (ret == RL_SUCCESS) {
    /* Echo back the message (Ping-Pong) */
    rpmsg_lite_send(info->instance, info->ept, master_ept_id, g_rx_buffer, msg_len, RL_BLOCK);
}

调用链非常清晰：rpmsg_queue_recv → env_get_queue → rt_mq_recv。在rt_mq_recv中，系统通过RT_DEBUG_NOT_IN_INTERRUPT宏进行了上下文检查：

c复制#define RT_DEBUG_NOT_IN_INTERRUPT                                             \
do {                                                                         \
    rt_base_t level;                                                         \
    level = rt_hw_interrupt_disable();                                       \
    if (rt_interrupt_get_nest() != 0) {                                      \
        rt_kprintf("Function[%s] shall not be used in ISR\n", __FUNCTION__); \
        RT_ASSERT(0)                                                         \
    }                                                                        \
    rt_hw_interrupt_enable(level);                                           \
} while (0)

这个检查的核心逻辑是：如果中断嵌套计数(rt_interrupt_get_nest())不为0，就认为当前处于中断上下文。问题在于，我们的代码明明是在线程中运行，系统却错误地认为我们在中断中。

2. 调试过程与问题定位

2.1 初步排查：栈溢出可能性

首先怀疑的是栈溢出导致寄存器值被破坏。我们检查了任务栈使用情况：

c复制rt_kprintf("Task stack size: %d, used: %d\n", 
           task->stack_size, 
           task->stack_size - rt_thread_self()->stack_size);

结果显示栈使用正常，没有溢出迹象。这个可能性被排除了。

2.2 添加调试打印确认中断状态

我们在调用rpmsg_queue_recv前添加了中断状态检查：

c复制if (rt_interrupt_get_nest() > 0) {
    rt_kprintf("rpmsgd WARNING: ISR Nest detected (%d) before recv! Aborting recv.\n", 
               rt_interrupt_get_nest());
    continue;
}

输出结果令人困惑：

code复制rpmsgd WARNING: ISR Nest detected (1) before recv! Aborting recv.
rpmsgd WARNING: ISR Nest detected (1) before recv! Aborting recv.
...
rpmsFunction[sys_mutex_lock] shall not be used in ISR
(0) assertion failed at function:sys_mutex_lock, line number:258

这表明中断嵌套计数确实被错误地设置为1，而且后续还出现了sys_mutex_lock的类似错误。

2.3 排查组件冲突：LWIP

通过grep查找sys_mutex_lock的使用情况：

bash复制grep -nr sys_mutex_lock

发现主要与LWIP网络组件相关。我们尝试移除LWIP组件后，sys_mutex_lock的错误消失了，但中断嵌套的问题依然存在：

code复制rpmsgd WARNING: ISR Nest detected (1) before recv! Aborting recv.
rpmsgd WARNING: ISR Nest detected (1) before recv! Aborting recv.
...

这说明LWIP是被影响者而非根源，我们需要继续深入。

2.4 中断处理异常分析

2.4.1 添加中断入口打印

我们在中断入口函数中添加了调试信息：

c复制void rt_hw_trap_irq(void) {
    int int_ack = rt_hw_interrupt_get_irq();
    int ir = int_ack & GIC_ACK_INTID_MASK;
    rt_kprintf("IRQ:%d N:%d\n", ir, rt_interrupt_get_nest());
    ...
}

关键输出如下：

code复制IRQ:176 N:1
IRQ:30 N:2
rpmsgd WARNIRQ:30 N:2
ING: ISR NeIRQ:30 N:2
st detectedIRQ:30 N:2
(1) beforeIRQ:30 N:2
recv! AborIRQ:30 N:2

2.4.2 中断序列分析

整理关键中断序列：

1. IRQ:176 N:1（Mailbox中断）触发
2. IRQ:30（定时器中断）触发，嵌套计数变为2
3. 之后rpmsgd线程检测到ISR Nest detected (1)

这表明Mailbox中断后，系统的中断嵌套计数没有正确清零，仍然保持为1，导致后续的定时器中断进入时计数变为2。

3. 根因分析与解决方案

3.1 问题根源

问题出在mailbox的中断处理函数中：

c复制static void rpmsg_mbox_isr(int irqn, void *param) {
    HAL_MBOX_IrqHandler(irqn, (struct MBOX_REG *)param);
    HAL_GIC_EndOfInterrupt(irqn); // 问题核心
}

RT-Thread的中断处理机制如下：

1. 通用中断入口rt_hw_trap_irq调用用户ISR回调
2. 用户回调返回后，内核会统一执行rt_hw_interrupt_ack（即GIC的EOI操作）

c复制void rt_hw_interrupt_ack(int vector) {
    HAL_GIC_EndOfInterrupt(vector);
}

问题在于rpmsg_mbox_isr手动调用了HAL_GIC_EndOfInterrupt，导致：

1. 第一次（手动）EOI告诉GIC"当前中断处理完毕"
2. GIC解除该优先级的屏蔽
3. 在ISR尚未真正退出（未执行rt_interrupt_leave减少嵌套计数）时，CPU已经可以响应新的同级或低级中断
4. 这种非预期的抢占破坏了内核对rt_interrupt_nest计数的维护逻辑

3.2 解决方案

正确的做法是移除用户回调中的冗余EOI操作，完全交由内核统一处理：

c复制static void rpmsg_mbox_isr(int irqn, void *param) {
    HAL_MBOX_IrqHandler(irqn, (struct MBOX_REG *)param);
    // 移除 HAL_GIC_EndOfInterrupt(irqn);
}

3.3 验证与测试

修改后重新测试，关键观察点：

1. 中断嵌套计数是否正确归零
2. rpmsg_queue_recv是否能正常执行
3. 系统稳定性是否改善

测试结果确认问题已解决，系统运行正常。

4. 深入理解RT-Thread中断机制

4.1 中断处理流程

RT-Thread在Cortex-A架构上的完整中断处理流程：

1. 硬件中断触发，跳转到rt_hw_trap_irq
2. 保存上下文，增加嵌套计数
3. 获取中断号，调用注册的ISR
4. ISR执行完毕，恢复上下文
5. 执行EOI操作，减少嵌套计数
6. 返回被中断的上下文

4.2 关键设计原则

1. 中断嵌套计数管理：

   • 进入中断时rt_interrupt_enter()增加计数
   • 退出中断时rt_interrupt_leave()减少计数
   • 必须严格配对使用

2. EOI操作时机：

   • 必须在内核完成所有中断处理后执行
   • 过早执行可能导致中断重入和计数错误

3. 中断上下文限制：

   • 不可调用可能导致阻塞的API
   • 不可进行内存分配等复杂操作

5. 经验总结与最佳实践

5.1 调试技巧

1. 中断问题排查checklist：

   • 检查嵌套计数是否正确
   • 验证EOI操作时机
   • 确认中断优先级配置
   • 检查中断屏蔽状态

2. 实用调试手段：

   • 在关键位置添加计数打印
   • 使用rt_interrupt_get_nest()实时监控
   • 检查中断返回地址

5.2 开发建议

1. 中断处理函数编写规范：

   • 保持ISR尽可能简短
   • 避免在ISR中执行复杂逻辑
   • 不要手动调用EOI相关函数

2. 核间通信实现要点：

   • 确保两端中断处理同步
   • 合理设计消息传递机制
   • 注意缓存一致性处理

3. AMP系统注意事项：

   • 核间资源共享管理
   • 调试信息收集方案
   • 异常处理协调机制

6. 扩展思考：RPMSG实现原理

6.1 RPMSG架构概述

RPMSG（Remote Processor Messaging）是核间通信的常用框架，主要组件：

1. VirtIO总线：提供抽象的通信机制
2. 共享内存：消息传递的物理载体
3. Mailbox/IPC：中断通知机制

6.2 RK3506实现特点

在RK3506上的特殊考虑：

1. 共享内存区域配置
2. 缓存一致性处理
3. 中断映射关系
4. 性能优化点

6.3 性能优化建议

1. 批处理消息减少中断频率
2. 合理设置缓冲区大小
3. 考虑使用轮询模式在高负载场景
4. 优化内存拷贝操作

7. 常见问题解答

7.1 为什么不能在中段上下文调用某些函数？

中断上下文有严格限制：

• 不能阻塞（无任务调度）
• 栈空间有限
• 执行时间需尽可能短

7.2 如何判断当前执行上下文？

使用RT-Thread提供的API：

c复制rt_interrupt_get_nest() > 0  // 中断上下文
rt_thread_self() != RT_NULL  // 线程上下文

7.3 核间通信调试有哪些技巧？

1. 两端添加同步调试信息
2. 使用逻辑分析仪抓取中断信号
3. 检查共享内存内容
4. 逐步验证通信链路

8. 结论与个人实践建议

通过这次调试经历，我深刻理解了RT-Thread中断机制的重要性。在嵌入式开发中，特别是涉及多核通信的场景，对中断处理的精确控制至关重要。以下是我的几点实践建议：

1. 严格遵守框架规范：不要随意添加框架本应处理的操作（如EOI）
2. 加强调试手段：建立完善的中断监控机制
3. 文档仔细阅读：深入理解所用RTOS的中断处理流程
4. 模块化测试：先验证基础功能，再构建复杂系统

在RK3506这类多核平台上开发时，建议先充分验证核间通信基础功能，再构建上层应用。同时，保持对系统状态的监控能力，可以大大缩短类似问题的排查时间。