Embassy项目在WCH CH583芯片上的中断处理问题分析

问题背景

在嵌入式开发领域，Embassy是一个基于Rust的异步执行框架，它提供了轻量级的任务调度和中断处理机制。最近在将Embassy移植到WCH CH583芯片（采用RISC-V QingKe V4A架构）时，遇到了系统定时器中断无法正常工作的问题。

问题现象

开发者在为CH583芯片开发时间驱动时发现，系统定时器中断（systick）在Embassy环境下无法正常触发，而在独立项目中却能正常工作。经过深入排查，发现问题源于执行器（executor）中的WFI（Wait For Interrupt）指令被放置在临界区内。

技术分析

WFI指令与临界区的交互

在RISC-V架构规范中，WFI指令有以下关键特性：

• 即使全局中断被禁用（如通过mstatus寄存器），WFI仍应被挂起的中断唤醒
• 唤醒后，中断处理会等到退出临界区后才执行

然而，在QingKe V4A架构中：

• 临界区实现通过gintenr寄存器完全禁用所有中断
• 实验表明WFI在这种状态下不会被唤醒，这与RISC-V规范不符
• 进一步测试发现，使用mstatus寄存器实现临界区也有同样问题

根本原因

这实际上是WCH CH583芯片的一个硬件缺陷：

• WFI在中断完全禁用状态下无法可靠唤醒
• 仅当中断在WFI后很短时间内（几毫秒内）发生时才能唤醒

解决方案探索

临时解决方案

将WFI移出临界区可以解决问题，但这会引入竞态条件风险：

1. 执行器检查工作标志（SIGNAL_WORK_THREAD_MODE）为false
2. 此时恰好发生中断并设置标志为true
3. 执行器进入WFI，导致死锁

硬件特性利用

CH583的PFIC（可编程快速中断控制器）提供了两个关键位：

1. WFITOWFE：将WFI转换为WFE（等待事件）行为
2. SEVONPEND：任何挂起的中断（即使被禁用）都会生成事件

启用这两个位后，中断行为变得符合预期，因为：

• 即使中断被禁用，挂起的中断也能唤醒处理器
• 这类似于ARM架构的WFE/SEV机制

长期解决方案

对于WCH芯片，建议的解决方案包括：

1. 在HAL中创建芯片特定的执行器实现
2. 不启用默认的arch-riscv特性
3. 基于原始riscv.rs实现进行定制
4. 利用WFITOWFE和SEVONPEND特性优化性能

技术启示

这一案例展示了在嵌入式开发中需要注意的几个重要方面：

1. 硬件实现可能与架构规范存在差异
2. 临界区和电源管理指令的交互需要特别关注
3. 芯片特定特性可以用于解决兼容性问题
4. 框架设计时应考虑为硬件差异留出扩展点

对于RISC-V生态而言，这也提醒我们虽然标准统一，但不同厂商的实现可能存在细微差别，需要在驱动和框架层面做好兼容性处理。