FreeRTOS阅读记录-task相关

本文详细介绍了FreeRTOS操作系统中任务的创建、初始化及调度过程。重点讲解了任务切换的实现机制,包括如何通过栈和TCB来表示任务状态,以及如何在中断和服务例程中进行上下文切换。

使用FreeRTOS也很长时间了,断断续续看过,现在记录,流程写出来不难,难的是进行高度简洁的总结。

在学校时,看过UCOS-II的代码,由于版权问题,不能使用。而FreeRTOS是基于 MIT open source license,可以免费发布,可以在商业中使用,在2019年EETimes调查中,FreeRTOS是使用量排名第三的OS。

先介绍task相关的部分

一个OS要把各个task进行管理,主要就完成2件事情,一是构造好代表各task的TCB和栈,二是进行线程切换时把上一个task的上下文保存好,并切换到下一个task,只要这2部分完成的没有问题,一个最简单的RTOS就实现了,至于各task的调度策略,支持事件等复杂功能,只是锦上添花。task的上下文保存在栈上,task的需要OS维护的信息保存在TCB中,因此一个task只使用TCB和栈就可以完全表示。

一:初始化

task创建就是把表示此task的TCB和栈初始化好,等待调度。task创建好后,TCB和栈如下:

第一个是栈指针,指向一个分配的内存,第一次初始化后,内容是要切换后执行的上下文。

xStateListItem 初始化为挂在对应优先级的Task链表上,这里没画出。Event为空,表示还没有事件。

二:任务第一次开启

是由vTaskStartScheduler()完成,先创建idle线程,之后调用 xPortStartScheduler(),在其中调用vStartFirstTask(),里面执行开中断,svc 2号调用,到svc服务函数中执行。

SVC_Handler 中调用 vPortSVCHandler_C,调用vRestoreContextOfFirstTask,流程如下:

                    -> r0 = pxCurrentTCB[0];    获取当前的psp,即创建的main的线程
                    -> mpu 相关,这里暂只分析不开mpu
                    -> ldm  r0!, {r1-r2}; /* Read from stack - r1 = PSPLIM and r2 = EXC_RETURN. */
                    -> msr  psplim, r1; /* Set this task's PSPLIM value. */
                    -> movs r1, #2; msr  CONTROL, r1; /* Switch to use PSP in the thread mode. */
                    -> adds r0, #32; msr  psp, r0; isb; /* 调整栈指针,跳过R4~R11,见上图 */
                    -> mov  r0, #0; msr  basepri, r0; /* 确保终端是打开的 */
                    -> bx   r2; /* 按 EXC_RETURN 返回,之前初始化是0xfffffffd,按中断中方式返回 */

注意返回时,硬件会自动从psp地址中弹出 R0~R3, R12, LR, PC,然后此时的CPU上下文就是线程创建时的栈的内容,然后CPU开始跑第一个线程。

三:任务切换

触发任务切换只有2种情况,第一个是被动触发,当中断发生(外设或tick中断),在中断中有信号量等释放,或计时到某个时间点,需要触发之前延时等待或超时的事件;第二个是主动触发,正在执行的线程执行了延时,或释放了信号量,或获取信号量未果等,主动触发了调度。这里举一个主动调用延时的例子:

vTaskDelay(xTicksToDelay)
    -> prvAddCurrentTaskToDelayedList( xTicksToDelay, pdFALSE );
        -> uxListRemove( &( pxCurrentTCB->xStateListItem ) );  从当前链表上移除,当前链表为正执行的任务,如果不是正执行的任务,不会调用delay函数
        -> vListInsert( pxDelayedTaskList, &( pxCurrentTCB->xStateListItem ) );  将当前函数移到DelayedTaskList上
        -> if( xTimeToWake < xNextTaskUnblockTime ) { xNextTaskUnblockTime = xTimeToWake; }
    -> if( xAlreadyYielded == pdFALSE ) portYIELD_WITHIN_API();    置位PENDSV中断,触发并跳入 pendsv 函数。

PendSV_Handler  @ portasm.c    src\kernel\FreeRTOSv10.4.x\Source\portable\GCC\ARM_CM33_NTZ\non_secure
    -> mrs r0, psp; mrs r2, psplim; ... #保存了 r2, r3 = lr = 0xfffffffd(中断上下文),保存当前的 psp 到 TCB
    -> mov r0, configMAX_SYSCALL_INTERRUPT_PRIORITY; msr basepri, r0; dsb; isb;  调整至最高优先级,以关闭中断
    -> bl vTaskSwitchContext;    @ tasks.c    src\kernel\FreeRTOSv10.4.x\Source
        -> taskSELECT_HIGHEST_PRIORITY_TASK();
                -> while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopPriority ] ) ) ) { --uxTopPriority; }  一直找到下一个最高优先级的task
                -> listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopPriority ] ) );  使用 idle 的 xStateListItem 把 pxCurrentTCB 赋值为下一个最高优先级的task的TCB
                -> uxTopReadyPriority = uxTopPriority;
    -> mov r0, #0; msr basepri, r0;  开中断
    -> ldr r2, pxCurrentTCB; ldr r1, [r2]; ldr r0, [r1];
    -> ldmia r0!, {r2-r11}  # 取出包括 r3 = return address

    -> msr psplim, r2;  #no MPU
    -> msr psp, r0; bx r3;  执行idle task的返回地址,此时为 0xfffffffd ,即从中断返回,从psp取出上下文,开始执行下一个最高优先级的线程

<think>首先,用户的问题是关于解决ESP-IDF v5.1.6 FreeRTOS回溯信息问题。他们提供了一个回溯信息: Backtrace: 0x403775bb:0x3fca6880 0x40378825:0x3fcd3b90 0x40385193:0x3fcd3ba0 0x40384d66:0x3fcd3bc0 0x420147f9:0x3fcd3c00 0x40378585:0x3fcd3c20 0x40384ead:0x3fcd3c50 用户提到esp-idf、FreeRTOS等框架,并参考了之前的引用,但这些引用似乎与回溯问题没有直接关系。引用[1]是关于导入ESP-IDF版本,引用[2]是ESP-IDF的介绍,引用[3]是关于MQTT错误0x8001和0x8006,引用[4]是关于编译失败和menuconfig问题。 用户说:“上述引用仅供参考,并不是用户真正的需求,请尽可能多的参考用户上一次的问题和你的回答。” 但在上下文里,这是第一个问题,所以我需要直接回应当前的查询。 核心问题:用户需要帮助解决回溯信息问题。回溯信息通常用于调试崩溃或错误,通过地址来定位代码中的位置。 在ESP-IDF环境中,回溯信息可以通过工具如addr2line或ESP-IDF提供的工具来解析地址到源代码位置。 步骤: 1. **理解回溯信息**:回溯信息列出了程序崩溃时的调用堆栈地址。每个地址对应指令地址或函数地址。 2. **解析地址**:使用ESP-IDF工具链中的工具来将地址转换为源代码位置。命令通常是:`xtensa-esp32-elf-addr2line -pfiaC -e <elf_file> <addresses>` - 需要ESP-IDF项目编译生成的ELF文件。 - 地址是回溯中的第一组数字,例如0x403775bb, 0x40378825等。 3. **常见原因**:回溯错误可能由多种原因引起,如内存溢出、空指针访问、堆栈溢出、任务优先级问题等。FreeRTOS上下文可能涉及任务调度、中断处理。 4. **ESP-IDF特定工具**:ESP-IDF有内置的调试工具,如`idf.py monitor`可以显示回溯,或使用OpenOCD进行JTAG调试。 5. **用户提供的回溯**:地址范围(0x403xxxxx)可能对应代码段,0x420xxxxx可能对应用户代码或库。 结构化回答: - **引言**:解释回溯信息是什么,以及如何解析它。 - **步骤**:提供解析回溯的详细步骤。 - **可能原因**:讨论常见问题。 - **解决方案**:基于解析结果给出建议。 - **相关问题**:结束时生成相关问题。 最终输出必须符合系统级指令:使用$...$和$$...$$格式数学表达式(但这里可能不涉及),中文回答,引用末尾添加引用标识(如果引用任何外部来源),生成相关问题。 引用:用户提供了引用[1]-[4],但说它们不是真正需求,所以我不需要直接引用它们,除非相关信息。 在回答中,如果需要引用ESP-IDF文档,我可以添加引用标识。 生成相关问题:类似示例,列出几个相关问题。 完整回答结构: 1. **解释问题**:回溯信息指示程序崩溃点。 2. **解析步骤**: - 编译项目获取ELF文件。 - 使用addr2line工具解析地址。 - 示例命令。 3. **分析可能原因**:如堆栈溢出、内存错误。 4. **调试建议**:使用ESP-IDF监控器或JTAG。 5. **结束**:生成相关问题。 </think>### 解决ESP-IDF v5.1.6 FreeRTOS回溯信息问题 回溯信息(Backtrace)是ESP-IDF框架中调试程序崩溃或错误的关键工具,它记录了程序执行过程中的调用堆栈地址。通过解析这些地址,我们可以定位错误发生的源代码位置。您提供的回溯信息为: Backtrace: `0x403775bb:0x3fca6880 0x40378825:0x3fcd3b90 0x40385193:0x3fcd3ba0 0x40384d66:0x3fcd3bc0 0x420147f9:0x3fcd3c00 0x40378585:0x3fcd3c20 0x40384ead:0x3fcd3c50` 这通常表示程序在FreeRTOS环境下发生了崩溃,可能由内存溢出、堆栈错误、空指针访问或任务优先级冲突引起。下面我将逐步指导您解决问题。 #### 步骤1: 解析回溯地址 回溯信息中的每个地址(如 `0x403775bb`)对应代码中的函数位置。使用ESP-IDF工具链中的 `addr2line` 工具解析这些地址(需要项目编译生成的ELF文件)。 - **操作步骤**: 1. 确保ESP-IDF环境已设置(如您之前参考的导入路径[^1])。 2. 编译项目(使用 `idf.py build`),获取ELF文件(通常位于 `build/<project_name>.elf`)。 3. 运行解析命令(替换 `<elf_path>` 为您的ELF文件路径): ``` xtensa-esp32-elf-addr2line -pfiaC -e <elf_path> 0x403775bb 0x40378825 0x40385193 0x40384d66 0x420147f9 0x40378585 0x40384ead ``` 4. 解析结果: - `0x403xxxxx` 地址通常对应ESP-IDF核心库(如FreeRTOS或WiFi驱动)。 - `0x420xxxxx` 地址可能对应您的用户代码(如自定义任务或函数)。 **示例输出**:工具会返回函数名、文件名和行号,例如: ``` main_task at /path/to/main.c:50 vTaskDelay at /esp-idf/components/freertos/tasks.c:120 ``` 这能精确标识错误源头(如 `0x420147f9` 指向您的代码文件)。 #### 步骤2: 常见原因分析 根据回溯地址模式,常见问题包括: - **堆栈溢出(Stack Overflow)**:FreeRTOS任务堆栈不足(地址如 `0x403775bb` 可能指向堆栈检查函数)。检查任务堆栈大小(在 `FreeRTOSConfig.h` 中设置 `configMINIMAL_STACK_SIZE`)。 - **内存访问错误**:如空指针访问或数组越界(地址 `0x40384d66` 可能对应内存管理函数)。 - **中断或任务优先级冲突**:FreeRTOS调度问题(地址 `0x40378825` 常见于 `vPortYield` 函数)。 - **ESP-IDF版本兼容性**:v5.1.6可能存在已知Bug(参考ESP-IDF GitHub Issues或文档[^2])。 #### 步骤3: 调试和修复建议 - **启用FreeRTOS调试**: - 在 `menuconfig` 中启用 `Component config → FreeRTOS → Enable FreeRTOS trace hooks`(如遇到menuconfig问题,参考引用[^4])。 - 增加堆栈大小:在任务创建时指定更大的堆栈(例如从1024字节增至2048字节)。 - **使用ESP-IDF监控工具**: - 运行 `idf.py monitor` 监视实时日志,错误信息会包括更详细的上下文(如任务名称)。 - 如果解析失败,检查ELF文件是否匹配编译版本(地址解析依赖于正确的ELF文件)。 - **代码级修复**: - 如果解析指向用户代码(如 `0x420147f9`),检查该位置是否存在资源访问冲突。 - 确保所有任务和中断处理程序遵循FreeRTOS最佳实践。 - **升级或修复ESP-IDF**: - 确认v5.1.6的已知问题(参考ESP-IDF官方文档或社区讨论)。如果问题持续,升级到最新稳定版(如v5.4.1)。 - 类似MQTT错误 `0x8001`(引用[^3]),可通过更新网络库修复。 #### 注意事项 - **工具依赖**:确保 `addr2line` 工具路径正确(位于ESP-IDF工具链目录)。如果解析结果为空,ELF文件可能不匹配或编译选项有误。 - **预防措施**:在调试后,启用 `CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK` 选项检测堆栈溢出。 - **性能影响**:解析回溯不会显著影响运行时性能,但堆栈调整可能增加内存消耗。 如果上述步骤未解决问题,请提供解析工具的输出日志,我可以进一步分析。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值