Zephyr RTOS内核基础：中断嵌套与优先级从一次现场崩溃说起去年冬天，我在一个工业网关项目上被一个中断问题折磨了整整三天。设备在实验室跑得好好的，一上产线就随机死机——不是死锁，是那种连调试串口都吐不出最后一个字符的硬死。用逻辑分析仪抓了三天，终于发现玄机：一个高优先级的中断服务函数里，居然调用了k_sem_give，而这个信号量恰好被一个低优先级中断里的k_sem_take等着。更致命的是，低优先级中断执行到一半时被高优先级打断，高优先级ISR试图释放信号量时，内核发现调度器状态不对，直接进了__ASSERT。这就是Zephyr中断嵌套的典型陷阱。今天这篇笔记，我把当时踩过的坑和后来啃源码的理解，掰开了揉碎了写出来。中断嵌套的硬件基础：谁在管优先级？先看Cortex-M系列。NVIC（嵌套向量中断控制器）硬件上支持最多256个优先级，但Zephyr通常只用4到16个（由CONFIG_NUM_IRQ_PRIORITIES控制）。硬件保证：高优先级中断可以抢占低优先级中断，这是NVIC的硬逻辑，RTOS管不了。但Zephyr在软件层面加了一层限制：默认情况下，中断服务函数里不允许调用任何可能触发上下文切换的API。为什么？因为中断上下文没有线程控制块（TCB），调度器不知道切给谁。如果你在ISR里调了k_yield，内核会直接panic。/