单步调试时一按Step就跑飞，很多时候不是代码真的乱跑，而是调试视角与目标真实执行状态没对上：符号没对齐、指令集状态不一致、中断打断单步、异常直接改写了PC，都会让你看起来像“跳到奇怪地址”。排查要抓住两件事，一是每一步之后PC和SP到底变成了什么，二是异常向量和堆栈是否把CPU引到了错误的入口。

　　一、TRACE32单步调试时程序跑飞怎么排查

　　先别急着反复点Step，先把跑飞的那一次变成可复现的证据链，确认是单步动作导致PC跳走，还是异常或复位把执行流切走。

　　1、先用寄存器视图把PC与SP盯住

　　在TRACE32里打开【View】→【Register】，单步前记下PC与SP，点击【Step】后立刻对比PC是否落在预期函数附近，同时看SP是否突然跳到很小或很大的地址，PC跳走但SP正常多半是符号或指令集状态问题，PC与SP一起异常更像是异常入口或栈损坏。

　　2、确认当前PC处的反汇编与源码是否对应同一份镜像

　　打开【View】→【Disassembly】，让反汇编窗口跟随PC，再打开【View】→【Source】，如果源码行与反汇编完全对不上，优先怀疑加载的ELF与板上实际运行镜像不是同一版本，或程序在运行时做了重定位但你仍在看旧地址。

　　3、把中断先控住再做单步验证

　　单步时最怕被周期性中断打断，表现为PC突然跳到向量入口或某个中断服务函数，建议先在安全窗口内把中断暂时屏蔽，再单步两三步确认主线是否稳定，稳定后再恢复中断继续排查是哪一路中断导致切走。

　　4、把单步动作换成断点方式验证是否真在当前指令处执行

　　在疑似跑飞前一行附近设置断点，例如在函数入口或关键分支处用【Break】窗口添加断点，然后用【Go】运行到断点再单步；如果Go能稳定命中但单步必跑飞，通常是单步触发了异常或调试资源不足，例如某些内存区域不支持软件断点，需要改用硬件断点。

　　5、检查是否存在看门狗复位或低功耗切换造成的假跑飞

　　有些板子单步变慢后看门狗会触发复位，或在低功耗切换时调试口短暂不可用，你会看到PC跳到复位向量附近，建议在跑飞瞬间观察复位原因寄存器或复位指示信号，同时把看门狗喂狗点临时前移，先排除复位造成的执行流重启。

　　6、核对MMU或缓存配置是否让取指地址与显示地址不一致

　　若系统启用了地址映射或缓存，单步时可能出现读到的代码与实际取指不一致，表现为反汇编像“乱码跳转”。可以先在初始化阶段停住，确认地址映射建立前后PC落点是否发生跳变，并核对当前正在执行的区域是否与链接地址一致。

　　二、TRACE32异常向量与堆栈设置应怎样核验

　　只要异常向量表基地址错了，或堆栈初始化错了，单步时稍微触发一次异常就会把CPU带到完全不相关的地址，看起来就像程序跑飞。核验时建议先校准向量入口，再校准栈，再用一次可控的异常断点把链路闭环。

　　1、确认异常向量表基地址指向了真实向量表

　　在【View】→【Register】中找到异常向量基址相关寄存器，确认它的值落在你期望的向量表区域，例如Flash起始或RAM重映射区，同时在【View】→【Memory】里直接查看该地址处的向量内容，确认复位向量与关键异常入口不是全零也不是全一。

　　2、逐条核对关键异常入口是否指向有效函数地址

　　重点看复位入口、HardFault入口与常用中断入口这几项，把它们指向的地址在反汇编窗口里打开，确认是合理的函数前序而不是未映射区或数据区；如果入口地址落在数据段或外设区，基本可以判定向量表内容被写坏或链接放置错位。

　　3、核对启动阶段对堆栈指针的初始化是否正确

　　查看系统上电后第一时间的SP值，确认它落在RAM栈区顶端附近，并且满足对齐要求；如果SP落在Flash或外设区，往往是启动文件未正确设置初始栈顶，或链接脚本里栈区定义与启动文件引用不一致。

　　4、检查异常入栈后的栈框是否合理

　　当怀疑异常导致跑飞时，在HardFault入口设置断点，命中后查看栈内保存的返回地址与状态寄存器内容，若返回地址明显不在代码段范围内，优先怀疑栈溢出或栈被越界写坏；这一步能把问题从“看起来跳走”变成“是谁把返回地址写坏”。

　　5、用栈边界监视把栈溢出抓现行

　　在栈底附近放置一段哨兵值，再设置内存写监视或周期性检查，发现哨兵被改写就说明栈已经触底；如果单步几次就触底，通常是栈设置过小或某个函数栈帧异常大，例如大数组放在栈上。

　　6、确认异常向量与堆栈区域的内存属性一致

　　如果向量表放在RAM且RAM在早期未初始化，或栈区在某些模式下不可写，例如MPU权限不允许写入，也会导致异常入栈失败并引发二次异常，建议把向量表与栈区的权限、可访问性在初始化阶段就确认清楚。

　　三、TRACE32符号加载与地址映射核对

　　不少跑飞其实是你看错了程序位置，或者符号与实际映像错位，导致你以为PC跳飞，实际只是显示不对。把符号与地址映射核对清楚，很多“跑飞”会立刻变成可解释的跳转。

　　1、确认TRACE32加载的符号文件与板上镜像一致

　　先核对构建时间与版本号信息，再在反汇编里挑一段有特征的指令序列，与固件镜像对应地址处做对比，避免拿旧ELF去调新镜像。

　　2、核对链接脚本中的代码段与数据段放置是否与启动方式一致

　　如果程序实际从RAM运行但链接地址仍指向Flash，或启动阶段做了代码搬运但调试器仍按链接地址解读，单步时就会出现跳转到看似不存在的地址，建议把搬运前后的执行基址在调试会话里明确下来。

　　3、核对指令集状态与入口地址最低位语义

　　某些架构会用入口地址的最低位表达指令集状态或分支语义，若入口地址处理不当，单步会落到半字对齐错误的地址并触发异常，表现为跑飞与HardFault反复出现。

　　4、把断点类型与存放区域匹配

　　当代码在Flash或受保护区域，软件断点可能无法落下或会改写失败，建议对关键位置优先用硬件断点，并把断点数量控制在合理范围，避免资源耗尽导致行为不稳定。

　　5、把问题定位到第一次偏离的那一条指令

　　不要追着跑飞后的地址看，应该在跑飞前一两步设置断点或单步，并记录每一步PC变化，找出第一次偏离预期的那条指令，再结合它的分支条件、异常触发条件与栈变化去定根因。

　　总结

　　TRACE32单步跑飞要先用PC与SP把现象钉死，再把中断、复位、异常入口这三条最常见的“改写执行流”的路径逐一排除；异常向量与堆栈核验则要从向量表基地址、入口内容、栈指针初始化与异常入栈后的返回地址四个点闭环确认。最后把符号加载与地址映射对齐，能避免把显示错位当成程序乱跑，排查效率会明显提升。