ThreadX 优先级问题

发表于 2026-3-19 13:05

正 STM32H745 和 ThreadX 实时操作系统开发的项目中，外部事件会触发 EXTI10 中断；在 HAL_GPIO_EXTI_Callback() 中断回调函数中，我调用了 tx_event_flags_set() 函数来启动一个需要执行特定操作的进程。
根据 ThreadX 的官方建议：从自定义中断处理函数中调用 RTOS 函数时，应将该中断分配为最低优先级，数值最大。但实际测试中发现：
当把 EXTI10 的抢占优先级设为 15 时，程序运行极不稳定；
当抢占优先级设为 0时，一切工作正常。
导致这一问题有哪些原因？

发表于 2026-3-19 14:52

在ARM Cortex-M中，中断优先级数值越小，优先级越高。抢占优先级决定了是否可以打断其他正在执行的中断。如果中断A的抢占优先级高于中断B，那么中断A可以打断B的执行。而子优先级则是在同一抢占优先级下决定执行顺序。

发表于 2026-3-19 14:53

根据ThreadX的建议，调用RTOS函数的中断应该设为最低优先级，即数值最大。你按照这个建议将EXTI10的抢占优先级设为15，但程序不稳定，而设为0时正常。这似乎与ThreadX的建议相悖。

发表于 2026-3-19 15:53

当EXTI10的抢占优先级设为15时，可能被其他更高优先级的中断打断，导致在调用tx_event_flags_set()时被中断，而RTOS函数可能不允许被中断打断，导致问题。而设为0时，没有其他中断能打断它，所以正常。

发表于 2026-3-19 17:54

ThreadX的函数可能要求在中断中调用时，该中断不能被其他中断打断，否则可能导致数据不一致或竞态条件。当抢占优先级设为0时，该中断不会被其他中断打断，所以安全。而设为15时，可能被其他中断打断，导致问题。

发表于 2026-3-19 18:54

高抢占优先级的中断可能在处理时被延迟，或者因为其他中断的打断导致响应时间不稳定，进而影响系统稳定性。

发表于 2026-3-19 19:54

可能存在其他配置错误，比如中断优先级分组设置不正确，导致实际优先级与预期不符。或者，EXTI10的中断处理函数本身存在缺陷，在高优先级时暴露问题。

发表于 2026-3-19 21:55

中断优先级配置错误吧

发表于 2026-3-19 22:56

可能未正确配置NVIC的优先级分组。

发表于 2026-3-19 20:56

在中断服务程序中，可能存在未清除中断标志、执行时间过长或调用非中断安全的函数等问题，导致不稳定。

发表于 2026-3-19 15:27

可能是硬件配置问题，如EXTI线路映射错误、GPIO配置错误、时钟未使能等，导致中断无法正确触发或处理。

发表于 2026-3-19 16:27

ThreadX使用优先级阈值和嵌套计数来保护临界区。如果中断优先级配置不当，可能导致临界区保护失效，引发竞态条件。

发表于 2026-3-19 19:28

系统中断可能具有固定或更高的优先级，与用户中断冲突，导致问题。

发表于 2026-3-19 14:59

在ARM Cortex-M中，中断优先级数值越小，优先级越高。ThreadX的任务优先级也是数值越小优先级越高。

发表于 2026-3-19 18:29

ThreadX建议将调用RTOS函数的中断设为最低优先级

发表于 2026-3-19 20:23

在STM32H7中，NVIC优先级分组需要正确配置，通常推荐分组4

发表于 2026-3-19 22:33

当EXTI10设为最低优先级时，可能被其他高优先级中断打断，而tx_event_flags_set()函数可能不是中断安全的，导致数据损坏或系统崩溃。

发表于 2026-3-19 17:04

将EXTI10设为15时系统不稳定，设为0时正常。这表明实际场景中，最低优先级中断可能被其他高优先级中断打断，导致tx_event_flags_set()执行时被抢占，引发竞态条件或数据损坏。

发表于 2026-3-19 15:05

ThreadX的临界区保护依赖优先级阈值。当线程进入临界区时，会临时提升自身优先级至阈值，防止被低优先级任务打断。若EXTI10设为最低优先级，可能被其他高优先级中断打断。此时调用tx_event_flags_set()可能破坏RTOS内部数据结构，导致系统崩溃。设为0时，无其他中断能打断它，RTOS函数可安全执行。

[STM32H7] ThreadX 优先级问题

相关帖子

浏览过的版块