GD32环境下FreeRTOS在定时器中断调用信号量卡死问题
定时器初始化如下：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
中断中调用信号量会导致中断嵌套问题吧。 信号量分配不合理，形成了死锁 在GD32环境下使用FreeRTOS时，如果在定时器中断中调用信号量（Semaphore）的操作，可能会导致卡死的问题。这是因为在中断上下文中，不能直接调用阻塞操作，包括等待信号量的操作 在定时器中断服务函数中直接调用xSemaphoreTake()等等待信号量的函数，会导致任务无法继续执行，从而导致系统卡死 一般可能在定时器中断服务函数中直接调用xSemaphoreGive()等释放信号量的函数，会导致信号量的计数增加，但没有任务能够及时获取到信号量，从而导致系统卡死 建议在定时器中断中尽量避免直接调用阻塞操作，包括等待信号量、释放信号量和删除信号量等 其实想避免可以通过设置标志位或使用消息队列等方式，在中断中仅进行一些简单的标记操作，具体的处理逻辑放到任务中进行 在定时器中断中使用xSemaphoreGiveFromISR()函数来释放信号量，而不是直接调用xSemaphoreGive()。这样可以确保信号量的释放操作在任务上下文中进行，避免中断上下文中的阻塞操作 如果需要在定时器中断中删除信号量，可以通过设置标志位，在任务中检测该标志位并进行删除操作。避免在中断上下文中直接删除信号量 你可以通过log的方式看看程序死到哪儿了 看你解决方法是降低优先级，有可能的，就是优先级的冲突会抢占的
页:
[1]