21、启动代码的调试技巧：如何用JTAG/SWD单步跟踪启动过程
说实话，很多嵌入式工程师写了好几年代码，却从来没真正看过芯片上电后到底干了什么。启动代码在他们眼里就是个黑盒子——编译、下载、跑起来就完事了。但一旦遇到上电就死机、外设初始化失败、中断不响应这类问题，你就得老老实实打开调试器，一步步跟进去看。
我个人习惯用J-Link配合Ozone或者直接上IAR/Keil的调试器。今天我就把这几年的调试经验掰开揉碎，跟你聊聊怎么用JTAG/SWD单步跟踪启动过程。
为什么非要单步跟踪启动代码？
你想想看，启动代码是C语言世界的入口。它负责三件大事：
- 建立栈指针——让C函数能正常调用
- 初始化数据段——把全局变量从Flash搬到RAM
- 跳转到main()——把控制权交给你的业务逻辑
这三步任何一步出问题，你的程序要么跑飞，要么死机。我在项目中遇到过好几次，明明代码逻辑没问题，但上电就是跑不起来。最后发现是链接脚本里RAM地址写错了，启动代码把数据搬到了不存在的地址上。这种问题，不看汇编单步跟踪，你根本找不到。
准备工作：调试环境搭建
在开始跟踪之前，你得确保几件事到位了：
| 工具/组件 | 说明 | 我踩过的坑 |
|---|---|---|
| 调试器（J-Link / ST-Link / DAP-Link） | 支持JTAG或SWD协议 | SWD只需要两根线，比JTAG省事，我一般优先用SWD |
| IDE或独立调试工具 | IAR、Keil、Ozone、OpenOCD+GDB | Ozone对启动代码的符号解析最干净，推荐试试 |
| 目标芯片的启动文件 | startup_xxx.s 或汇编源文件 | 有些IDE默认不加载汇编源码，得手动设置 |
| 链接脚本（.ld / .icf） | 定义了RAM/Flash的地址布局 | 我习惯把链接脚本打印出来贴在桌上，调试时对照着看 |
第一步：从复位向量开始
芯片上电后，硬件自动从向量表取出复位向量，跳转到那里执行。这个地址通常就是启动代码的第一条指令。
在调试器里怎么做？很简单：
- 连接调试器，下载程序
- 在复位向量处设置断点（或者直接让调试器停在main之前）
- 按复位按钮，然后单步执行
我记得第一次跟踪STM32F4的启动代码时，发现复位向量指向的是Reset_Handler。这个函数里做了几件事：
Reset_Handler:
ldr sp, =_estack /* 设置栈指针 */
bl SystemInit /* 初始化时钟、PLL等 */
bl __main /* 进入C运行时初始化 */
嗯，这里要注意：__main不是你的main()函数，它是编译器提供的C运行时初始化函数。它会帮你完成数据段搬运、BSS段清零、构造函数调用等操作，最后才跳转到你的main()。
第二步：单步跟踪数据段初始化
这是最容易出问题的地方。说白了，启动代码要把Flash里的初始值搬到RAM里。如果搬错了地址，或者搬少了长度，全局变量的值就是错的。
我建议你在调试器里这样操作：
- 在
__main或__libc_init_array处设置断点 - 单步进入，观察寄存器R0、R1、R2的值
- R0 = 源地址（Flash），R1 = 目标地址（RAM），R2 = 数据长度
.data段的起始地址和结束地址，跟链接脚本一一对照。
第三步：观察BSS段清零
BSS段存放的是未初始化或初始化为0的全局变量。启动代码会把它全部清零。这一步如果漏了，你的变量可能带着随机值上电。
在调试器里，你可以：
- 在BSS清零循环处设置断点
- 观察循环计数器（通常是R4或R5）
- 在Memory窗口查看RAM区域，确认清零前后数据变化
我习惯在清零循环执行前后各抓一次RAM的快照，对比一下。如果发现某个地址没被清零，那多半是链接脚本里BSS段的边界定义错了。
第四步：检查栈指针和堆指针
栈和堆是C语言的命根子。栈指针在启动代码一开始就设置了，堆指针则在__user_initial_stackheap或类似函数中初始化。
调试时，我通常会：
- 在
Reset_Handler的第一条指令处，查看SP寄存器的值 - 确认SP指向的地址在RAM范围内，且没有超出RAM的末尾
- 在进入main()之前，再次查看SP，确认栈没有被意外修改
核心逻辑：启动代码调试流程图
下面这张图是我自己总结的启动代码调试流程，每次遇到启动问题，我就按这个顺序排查：
实用技巧：调试器里的几个骚操作
这些年我积累了一些小技巧，分享给你：
- 使用表达式窗口：在调试器里输入
_sdata、_edata、_sbss、_ebss这些链接器符号，可以直接看到它们的值。对照链接脚本，一眼就能看出问题。 - 设置硬件断点：启动代码里有些地方不能用软件断点（比如Flash还没初始化时）。我习惯在复位向量处用硬件断点，确保万无一失。
- 记录寄存器变化：在Ozone或IAR里，可以开启寄存器变化日志。单步执行时，系统会自动记录每次SP、PC、R0-R3的变化。这对分析启动流程非常有用。
Reset_Handler、SystemInit、__main、main这四个地方各设一个断点。然后按一次运行键，观察一次关键寄存器和内存。这样走完一遍，启动过程就清清楚楚了。
避坑指南：我踩过的三个坑
最后，我把自己踩过的坑列出来，你遇到了可以直接对照：
- 向量表偏移：有一次我把程序放在0x08010000（Bootloader之后），但忘了设置SCB->VTOR。结果中断向量表还是指向0x08000000，一进中断就跑飞。调试时发现复位向量是对的，但中断向量全乱了。解决办法是在SystemInit里设置VTOR。
- 栈空间不足：一个项目里用了大量局部变量和递归调用，栈空间只有1KB。启动时没问题，但跑几分钟就死机。后来在调试器里用栈填充模式（0xDEADBEEF），跑一段时间后查看栈空间，发现已经用到了0xDEADBEEF区域。加大栈空间后问题解决。
- 数据段搬运顺序：某个芯片的启动代码先搬运了.data段，然后才清零.bss段。但.data段和.bss段在RAM里是相邻的，搬运.data时把.bss区域覆盖了。清零时又把.data的末尾给清了。结果某些全局变量值不对。后来我修改了链接脚本，在.data和.bss之间留了4字节的间隙，问题解决。
嗯，调试启动代码其实没那么神秘。说白了就是一步步跟进去，看寄存器、看内存、看链接脚本。只要你掌握了今天说的这些技巧，下次遇到启动问题，就不会一头雾水了。
公众号:蓝海资料掘金营，微信deep3321