RT-Thread 启动流程详解：从复位入口到线程调度
做 RT-Thread 移植或排查启动异常时，最容易卡住的地方往往不是某一行代码，而是“不知道系统现在启动到了哪一步”。本文按实际调试视角，把 RT-Thread 从芯片复位到进入线程调度的主线梳理一遍，并总结一些常见踩坑点。
1. 启动链路总览
RT-Thread 的启动大致可以理解为下面这条链路：
芯片复位 -> Reset_Handler -> 初始化栈、data、bss、SystemInit -> 进入 C 运行环境 -> rtthread_startup() -> rt_hw_board_init() -> rt_system_timer_init() -> rt_system_scheduler_init() -> 创建 main 线程 -> rt_thread_startup(main_thread) -> rt_system_scheduler_start() -> main() / 自动初始化组件不同 BSP、不同芯片厂商的启动文件会有差异，但核心思想基本一致：先把硬件和 C 运行环境准备好，再初始化 RT-Thread 内核对象，最后开启调度器。
2. Reset_Handler：真正的起点
单片机复位后，CPU 会从中断向量表中取出初始栈顶和复位入口地址，随后跳转到Reset_Handler。这里通常由启动汇编文件完成几件事：
- 设置 MSP 主栈指针；
- 拷贝
.data段到 RAM； - 清零
.bss段； - 调用
SystemInit()配置时钟等底层资源； - 跳转到 C 层入口。
很多“程序跑飞”“变量初值异常”“一进 main 就 HardFault”的问题，都可能和启动文件、链接脚本、栈地址或内存段配置有关。
3. rtthread_startup：RT-Thread 的系统入口
进入 C 环境后，RT-Thread 通常会调用rtthread_startup()。这个函数是系统启动的核心入口，负责把内核运行所需的基础模块串起来。
典型流程包括：
- 关闭中断，避免初始化阶段被打断；
- 初始化板级硬件
rt_hw_board_init()； - 初始化系统 tick、定时器、调度器；
- 初始化信号、内存堆、设备框架等组件；
- 创建并启动 main 线程；
- 启动调度器。
调试时可以在rtthread_startup()入口、rt_hw_board_init()、rt_system_scheduler_start()这几个位置打断点，快速判断系统卡在哪一段。
4. rt_hw_board_init：板级初始化的关键点
rt_hw_board_init()一般位于 BSP 目录中，和具体芯片、板卡强相关。常见工作包括：
- 初始化系统时钟；
- 初始化 SysTick 或硬件定时器；
- 初始化串口 console；
- 初始化堆空间；
- 注册基础外设驱动。
如果串口没有输出，优先检查这里：时钟是否正确、串口引脚是否复用、波特率是否一致、console 设备名是否配置正确。
5. Tick 与调度器初始化
RT-Thread 依赖系统 tick 推动时间片、延时和定时器逻辑。tick 没有正常工作时，常见现象是：
rt_thread_mdelay()后不再返回；- 定时器回调不触发；
- 线程切换行为异常；
- shell 看起来卡住。
调度器初始化完成后，线程对象可以被加入就绪队列，但真正开始运行线程，要等到rt_system_scheduler_start()。
6. main 线程不是裸机 main
在 RT-Thread 中，应用层main()通常运行在 main 线程里，而不是传统裸机意义上的唯一入口。也就是说：
main()已经处在线程上下文；- 可以使用延时、互斥量、信号量等 RTOS API；
- 不建议在
main()里长时间关中断； - 如果
main()返回，要确认系统后续线程仍然能正常运行。
这也是很多裸机工程迁移到 RTOS 时需要转变的地方：不要把main()当成永不退出的大 while 容器，而要按线程模型组织功能。
7. 自动初始化机制
RT-Thread 有一套自动初始化机制，常见宏包括：
INIT_BOARD_EXPORT()：板级初始化阶段；INIT_PREV_EXPORT()：较早的组件初始化；INIT_DEVICE_EXPORT()：设备初始化；INIT_COMPONENT_EXPORT()：组件初始化；INIT_APP_EXPORT()：应用初始化。
这些函数不是凭空调用的，而是通过链接段收集起来，再按启动阶段统一执行。踩坑最多的是链接脚本没有保留这些段，导致初始化函数明明写了，却完全没有执行。
8. 常见踩坑点
8.1 栈太小
启动阶段、线程切换、printf、复杂中断回调都会消耗栈。栈太小时，现象可能不是立即报错，而是随机 HardFault、变量被覆盖、线程行为混乱。
建议开启栈溢出检查，并适当加大 main 线程和中断栈。
8.2 heap 范围配置错误
如果rt_system_heap_init()的起止地址不正确，动态内存分配会出现非常隐蔽的问题。常见表现包括线程创建失败、设备注册失败、组件初始化失败。
排查时重点看 map 文件，确认 heap 没有和栈、全局变量、外设 RAM 区域重叠。
8.3 SysTick 时钟源不对
系统主频修改后，如果 tick 配置没有同步更新，延时和调度节拍都会失准。表现为延时不准、线程切换频率异常，甚至系统看起来像卡住。
8.4 中断优先级配置不合理
在 Cortex-M 上，RTOS 对中断优先级有要求。优先级配置错误时，在中断中调用 RT-Thread API 可能导致断言、死锁或不可预期行为。
8.5 自动初始化函数没有被链接
如果新增驱动或组件后没有执行初始化，检查链接脚本中是否保留了 RT-Thread 自动初始化段。尤其是从一个 BSP 迁移到另一个工程模板时，这个问题很常见。
9. 推荐排查顺序
遇到 RT-Thread 启动失败，可以按下面顺序定位：
- 确认程序是否进入
Reset_Handler； - 确认
.data、.bss初始化是否正常； - 确认是否进入
rtthread_startup()； - 在
rt_hw_board_init()内逐步排查时钟、串口、heap； - 确认 tick 中断是否持续进入；
- 确认 main 线程是否创建成功；
- 确认调度器是否启动；
- 检查自动初始化段是否生效。
10. 总结
RT-Thread 的启动流程看起来步骤很多，但主线并不复杂：先完成芯片和 C 运行环境初始化，再初始化内核基础设施，然后创建 main 线程并开启调度。
真正调试时，不要一上来就怀疑业务代码。先把启动链路拆开，在关键节点打断点，确认系统走到了哪一步，再结合串口、map 文件、栈和 heap 配置逐段排查。这样定位会快很多，也更不容易陷入“代码看起来都对，但系统就是不跑”的困境。
