打印
[研电赛技术支持]

GD32环境下FreeRTOS在定时器中断调用信号量卡死问题

[复制链接]
2785|12
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
tpgf|  楼主 | 2024-3-13 13:07 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
定时器初始化如下:
timx_init(T1, 83, 999, 0, 1);
其中0为prePriority

在TIMER1_IRQHandler中调用
xSemaphoreGiveFromISR时

Keil仿真后程序卡在configASSERT( ucCurrentPriority >= ucMaxSysCallPriority )

排查原因:定时器的中断优先级大于系统能够管理的优先级。

解决办法:将定时器的优先级降低,即修改定时器初始化的prePriority

timx_init(T1, 83, 999, 9, 1);

完美解决!!!
————————————————

                            版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原文链接:https://blog.csdn.net/baidu_38324026/article/details/136621243

使用特权

评论回复
沙发
朝生| | 2024-3-27 18:31 | 只看该作者
中断中调用信号量会导致中断嵌套问题吧。

使用特权

评论回复
板凳
shenxiaolin| | 2024-4-30 16:17 | 只看该作者
信号量分配不合理,形成了死锁

使用特权

评论回复
地板
Betty1299| | 2024-5-17 11:31 | 只看该作者
在GD32环境下使用FreeRTOS时,如果在定时器中断中调用信号量(Semaphore)的操作,可能会导致卡死的问题。这是因为在中断上下文中,不能直接调用阻塞操作,包括等待信号量的操作

使用特权

评论回复
5
Charlotte夏| | 2024-5-17 12:36 | 只看该作者
在定时器中断服务函数中直接调用xSemaphoreTake()等等待信号量的函数,会导致任务无法继续执行,从而导致系统卡死

使用特权

评论回复
6
Estelle1999| | 2024-5-17 14:02 | 只看该作者
一般可能在定时器中断服务函数中直接调用xSemaphoreGive()等释放信号量的函数,会导致信号量的计数增加,但没有任务能够及时获取到信号量,从而导致系统卡死

使用特权

评论回复
7
Emily999| | 2024-5-17 16:25 | 只看该作者
建议在定时器中断中尽量避免直接调用阻塞操作,包括等待信号量、释放信号量和删除信号量等

使用特权

评论回复
8
Betty996| | 2024-5-17 18:00 | 只看该作者
其实想避免可以通过设置标志位或使用消息队列等方式,在中断中仅进行一些简单的标记操作,具体的处理逻辑放到任务中进行

使用特权

评论回复
9
Carmen7| | 2024-5-18 08:33 | 只看该作者
在定时器中断中使用xSemaphoreGiveFromISR()函数来释放信号量,而不是直接调用xSemaphoreGive()。这样可以确保信号量的释放操作在任务上下文中进行,避免中断上下文中的阻塞操作

使用特权

评论回复
10
alxd| | 2024-5-18 09:17 | 只看该作者
如果需要在定时器中断中删除信号量,可以通过设置标志位,在任务中检测该标志位并进行删除操作。避免在中断上下文中直接删除信号量

使用特权

评论回复
11
Carina卡| | 2024-5-18 10:23 | 只看该作者
你可以通过log的方式看看程序死到哪儿了

使用特权

评论回复
12
B1lanche| | 2024-5-18 12:03 | 只看该作者
看你解决方法是降低优先级,有可能的,就是优先级的冲突会抢占的

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

1931

主题

15650

帖子

12

粉丝