问题记录 freertos程序卡死在xQueueSendFromISR

最新推荐文章于 2025-04-28 00:17:24 发布
最新推荐文章于 2025-04-28 00:17:24 发布
阅读量251 收藏
点赞数 3
分类专栏： gd32相关 文章标签： 单片机 嵌入式硬件
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yangchenglin927/article/details/145930418
版权

解决：
将freertosconfig.h文件中 的 #define configMAX_SYSCALL_INTERRUPT_PRIORITY 6

然后NVIC_EnableIRQRequest(COM2_IRQn,7,0); 使用的中断优先级低于配置的configMAX_SYSCALL_INTERRUPT_PRIORITY的值。

STM32CubeMX生成freertos默认设置卡死，卡在HAL_Init不动，裸机运行程序正常跑，解决方法
weixin_44597885的博客
09-01 1055
最近通过STM32CubeMX生成freertos发现任务不执行，卡在HAL_Init不动，网上找很久不好使，刚开始怀疑硬件问题，但是裸机运行程序正常跑，然后怀疑软件有问题，但是对F1,F3系列都好使，仅仅对F4系列不行，然后通过对F4固件包升级得以解决。
c语言 执行free函数程序被卡住,FreeRTOS操作系统，在按键中断函数中恢复被挂起的任务，程序卡死的原因和解决办法...
weixin_33587161的博客
05-24 1398
FreeRTOS操作系统，在按键中断函数中恢复被挂起的任务，程序卡死的原因和解决办法时间：2019-08-10 14:39:47来源：作者：所属栏目：其他服务端这里将告诉您FreeRTOS操作系统，在按键中断函数中恢复被挂起的任务，程序卡死的原因和解决办法,教程操作方法:出现问题场景：作为刚接触FreeRTOS实时操作系统的菜鸟，我在练这里将告诉您FreeRTOS操作系统，在按键中断函...
FreeRTOS，串口中断接收中使用xQueueOverwriteFromISR()函数，程序卡死在configASSERT
zhai17863966493的博客
08-15 1312
FreeRTOS串口接收中断卡死
Freertos按键按下导致使系统停滞#正点原子#按键#程序卡死
Grasp_z的博客
10-24 819
在我们按下按键发现程序卡死的原因在于上述红圈的延时函数与Freertos不匹配，导致系统卡死。解决办法：将上面延时函数用Freertos中的vTaskDelay(10);
xQueueSendFromISR() 和 xQueueSend()应用对比
xu_wenming的博客
03-26 938
在 FreeRTOS 中，和是用于向队列发送数据的两个关键函数，但它们的用途、行为和使用场景有显著差异。
在中断服务程序（ISR）中直接调用阻塞式 xQueueSend()导致系统崩溃，解决方法
xu_wenming的博客
03-28 874
/ 优先级数值需大于 configMAX_SYSCALL_INTERRUPT_PRIORITY。通过以上方法，可以在中断中安全地使用队列，确保系统的实时性和稳定性。// 3. 触发任务切换（如果有更高优先级任务就绪）// 处理队列满的情况（如记录错误）// 2. 发送数据到队列（中断安全方式）// 队列已满，记录错误或采取恢复措施。// 原错误代码（在中断中使用阻塞式API）// 正确代码（使用中断安全API）// 处理队列创建失败。// FreeRTOS 队列句柄。// 1. 清除中断标志。
FREERTOS 中断调用 xQueuesendFromlSR错误解决
lexiaoyao201212的专栏
05-24 776
COnfigLIBRARY MAX SYSCALL INTERRUPT PRIORITY是Ox01.COnfigLIBRARY_LOWEST INTERRUPT PRIORITY是Ox0F 即15;把使用xQueuesendFromlSR 的中断函数抢占优先级配置成1（包含）以下就可以了。在单片机中断中调用消息队列函数 xQueuesendFromlSR 时程序出现假死状态，经过一番不懈努力的折腾，终于找到问题。是FreeRtos管理优先级问题。也就是说，FREERTOS只能管理优先级是1-15的中断。
FreeRTOS--XQueueReceiveFromISR
学海无涯，回头是岸........
10-12 9930
XQueueReceiveFromISR-FreeRTOS APIportBASE_TYPE xQueueReceiveFromISR( xQueueHandle pxQueue, void *pvBuffer, portBASE_TYPE *pxTaskWoken );从队列接收一个项目。在中断程序中使用此函数是安全的。 参数: pxQueue 发送项
ADC_DMA程序移植FreeRTOS出现在configASSERT行卡死的情况
u014034795的专栏
03-13 951
FreeRTOS移植HC32F448程序时，出现configASSERT卡死情况，DMA中断和freeRTOS先后运行顺序导致此现象，修改参数即可解决问题。
STM32F103C8T6，程序卡死，停在SysTick_Handler B. ，问题定位过程
最新发布
汽车电子软件领域知识分享
04-28 1050
针对 STM32F103C8T6 程序卡死在 `SysTick_Handler` 的问题，本文给出了详细的定位过程和解决思路。
freertos卡死在sys
03-25
首先，用户提到了FreeRTOS卡死在sys调试的情况，可能涉及系统初始化、任务调度或中断处理的问题。我需要回忆一下FreeRTOS常见的卡死原因和解决方法，同时结合用户提供的引用内容来分析。 首先，用户提供的引用[2]...
STM32+HAL+FreeRTOS串口接收一批数据后随机卡死bug的解决办法与详细探索思路（发送函数和接收函数不能同时使用）
wuwenbin12的博客
09-09 6616
项目背景： keil5+HAL库+FreeRTOS系统+STM32H743，存在两个同等优先级的任务，一个任务通过串口读取数据，一个任务通过串口发送数据，从而与其他设备进行信息的交互。 问题描述：网络调试助手以20HZ频率往单片机串口发数据，每次数据包共11字节。大概成功接收四百次之后，串口直接进不了接收中断。而串口对外发送任务正常进行，说明系统并未卡死。 不想看猜想过程的可以直接滑到最后一个猜想，就是问题的解决方案。 猜想1：和波特率有关系 任务发送数据包一共11字节，即88bit。以20HZ
276_浮点运算导致FreeRTOS卡在xQueueGiveFromISR
小灰笔记
02-25 2772
完整的S32K144的学习汇总如下： https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，这一次整理一个我在学习中遇到的BUG。我的软件中有一个基于串口的printf功能，最初这个功能都是OK了。但是，当我增加了一个浮点运算之后，打印了一下之后不再打印了。使用调试器，查看到软件停在了xQueueGiveFromISR函数中。 ...
FreeRTOS中xQueueSend写入数据失败原因分析
kivenx的博客
02-27 683
xQueueSend失败原因分析
FreeRTOS队列：xQueueCreate()，xQueueSendToBack()，xQueueSendToFront()，xQueueReceive（），xQueueSendFromISR（）
gs_bfsyrgz的博客
03-05 1012
FreeRTOS 队列（Queue）是其任务间通信的核心机制之一，用于在任务之间或任务与中断服务程序（ISR）之间安全地传递数据。：队列有固定长度，每个队列项的大小在创建时指定。：队列是一种先进先出（FIFO）的缓冲区，允许多个任务或中断以线程安全的方式发送和接收数据。：若多个高优先级任务依赖同一队列，需考虑优先级继承机制（如使用互斥锁）。：当队列已满时，发送任务可选择等待指定时间（直到有空间）。：频繁操作队列可能影响实时性，需合理设计队列长度和项大小。），需指定队列长度和每个队列项的大小。
FreeRTOS中断调用API消息队列发送函数导致系统死机（memcpy函数卡死）
qq_27132149的博客
01-11 4198
另一种中断中调用FreeRTOS的消息队列发送函数卡死情况，与网上案例不同
FreeRTOS中断调用api卡死
绝对只有原创
04-15 8041
stm32+freertos。 这里我要说的是发生这种情况的另一种解决办法。 先说背景。 本来是要实现一个简单的功能，就是从串口接收数据通过队列发送给其中一个任务进行处理。 最先的问题是由于stm32的串口没有fifo，按照网上的资料实现了dma加空闲中断，这个问题就出现在空闲中断上。 反映出来的现象就是出现中断后程序没反映了，但是打断点调试又能正
freertos程序死机原因
热门推荐
WIP56的博客
10-09 1万+
一、开机死机原因 1.一般是某任务栈溢出所致 栈溢出一般有两个原因： 1).此任务函数的代码量太大,或调用了某个比较大的函数。 2).此任务的函数内有比较大的局部变量的数组 调试方法： 1、先关闭所有任务再逐个打开，确定哪个任务导致的死机 2、先看看有没有较大的数据，再用水印函数看看函数的剩余栈。 uxTaskGetStackHighWaterMark(Task_sendModebuHandle ) 举例：打开此任务函数时死机，原因是 uint8_t buff[1050]太大栈溢出所致 osTh
freertos调度卡死
09-22
在你的代码中，当你添加了业务功能代码时，四个任务都卡死了，这可能是因为业务功能代码导致了任务调度问题。在FreeRTOS中，任务调度是基于时间片轮转的，每个任务在执行完一定时间后会被调度到另一个任务上。但是，如果某个任务在执行过程中长时间阻塞或者死锁，那么其他任务就无法得到执行，从而导致了任务卡死的现象。 在你的情况下，添加的业务功能代码可能导致了任务的长时间阻塞或者死锁。你可以尝试以下几个方法来解决这个问题： 1. 检查业务功能代码中是否存在死循环或者长时间阻塞的情况。如果有，你需要修改代码，确保任务能够及时释放CPU资源，让其他任务得到执行的机会。 2. 检查任务的优先级设置是否合理。如果某个任务的优先级设置过高，它可能会长时间占用CPU资源，导致其他任务无法得到执行。你可以尝试调整任务的优先级，确保任务之间的相对重要性和紧急程度得到合理的反映。 3. 检查任务的堆栈大小是否足够。如果任务的堆栈空间不足，它可能会导致堆栈溢出，从而引发任务卡死的问题。你可以尝试增加任务的堆栈大小，确保任务能够正常运行。 4. 使用调试工具来定位问题。FreeRTOS提供了一些调试工具，例如FreeRTOS Trace，可以帮助你追踪任务的调度情况和堆栈使用情况，从而找出问题所在。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值