基于Silicon Labs EFM Tiny-Gecko的RTX isr_evt_set服务延迟问题求助

根据你描述的硬件和软件环境，我来帮你一步步分析可能的原因并给出解决思路：

1. 先明确ARM NVIC优先级的核心规则 #

首先要纠正一个很容易搞混的点：ARM NVIC的优先级数值越小，优先级越高。你设置的SysTick和PendSV优先级是224，这属于非常低的优先级（255为最低）。如果你的RTC中断优先级数值比224小（也就是优先级更高），那么当RTC中断执行时，即使isr_evt_set()触发了PendSV，PendSV也必须等RTC中断完全退出后才能被响应——如果RTC中断服务程序（ISR）本身执行时间很长，这直接就是延迟的根源。

2. 检查RTC ISR的执行时长 #

这是最常见的原因：

• 你有没有在RTC ISR里做非必要操作？比如复杂计算、外设IO操作、甚至等待某个状态？
• 建议用示波器或Simplicity Studio的调试工具测量RTC ISR的执行时间。如果ISR执行时间超过了你能接受的延迟阈值，必须把非紧急逻辑移到任务中处理，只在ISR里做最核心的事：比如调用isr_evt_set()设置事件标志，然后立即退出。

3. 核对NVIC分组与优先级配置 #

你提到的“NVIC分组7.1”可能表述有误，ARM标准NVIC分组为0~7，对应抢占优先级位数从4到0、子优先级位数从0到8：

• 如果是分组7，意味着所有中断只有子优先级，没有抢占优先级——高子优先级的中断无法抢占正在执行的低子优先级中断，若PendSV的子优先级比RTC低，就必须等RTC ISR结束才能执行。
• 建议确认RTC中断的优先级数值：如果RTC优先级比PendSV高（数值更小），优先考虑优化RTC ISR的执行时间，而非随意调整PendSV优先级（PendSV通常设为低优先级，避免打断关键中断）。

4. 验证RTX API的使用正确性 #

• 确保调用isr_evt_set()时传入的任务ID正确，且目标任务确实在通过os_evt_wait()（或对应版本的等待事件API）等待该事件标志。如果任务未处于等待状态，isr_evt_set()只会设置标志，不会立即唤醒任务，这看起来像延迟，但实际是逻辑问题。
• 由于你不确定RTX版本，建议查阅对应版本的文档：老版本RTX的isr_evt_set()实现可能有差异，比如是否需要手动触发调度，但通常该API会自动触发PendSV完成调度。

5. 排查系统中其他高优先级中断 #

检查系统中是否有其他中断的优先级比PendSV高（数值<224）：

• 如果这些中断在RTC触发后频繁执行，会抢占PendSV的执行，导致任务调度延迟。
• 可以通过调试工具查看中断触发时序，确认是否有其他中断抢占了PendSV的响应。

6. 确认寄存器状态的一致性 #

你说PRIMASK和BASEPRI都是0，但要确保RTC ISR执行过程中，没有第三方库、驱动等代码临时修改这两个寄存器：

• 比如某些驱动可能会临时设置BASEPRI屏蔽低优先级中断，却未正确恢复，导致PendSV无法及时响应。
• 可以在RTC ISR的入口和出口处添加调试代码，读取这两个寄存器的值，确认它们始终保持为0。

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