调试人员在用TRACE32这个工具看芯片启动的时候，复位操作表面上就是点一下那个【Reset】按钮，或者在控制台敲一个SYStem.Up命令，但是其实里面有很多别的事情在影响最后的结果。大家要是碰到TRACE32复位流程怎么配置，或者TRACE32复位后程序入口跳转异常怎么办这类情况，调试人员不能光看程序最后有没有重新跑起来，还要去检查复位具体是用哪种方式搞的，调试器和板子是怎么连上的，CPU有没有死死停在reset vector这个地方，PC寄存器的初始数值对不对，以及向量表和启动地址到底能不能对得上。

　　一、TRACE32复位流程怎么配置

　　我们在配置TRACE32的复位流程时，要把目标芯片、调试用的接口，还有启动的介质放在一块儿来考虑。因为每种芯片的reset动作表现得都不太一样，有的芯片在复位之后直接就停在复位向量那边了，有的芯片复位完还会自己往下跑，还有的芯片得先走完内部的BootROM和Bootloader，最后才轮到应用程序，所以我们在写脚本的时候，必须要把“连接、复位、加载、停机、运行”这几个具体的动作先后顺序写个明白。

　　1、先区分SYStem.Up和Attach

　　如果调试人员打算在平台复位过去之后让TRACE32管住目标，这时候大家一般要用SYStem.Up命令，或者去跑对应的Up流程；要是程序本身已经跑起来了，调试人员只是想中途插进去看看，那用SYStem.Mode Attach这个命令会更合适一些。我们在调试启动过程的时候，经常要选到底是在平台复位以后就进到调试状态，还是等启动跑了一阵子再去附加调试。

　　2、把复位和加载顺序写清楚

　　我们平时写脚本的常见顺序大概可以这样理解：先选好对应的CPU，接着让调试器连接目标，然后把ELF文件或者符号表加进来，最后再去设置断点让它运行。要是做普通的RAM调试，调试人员可以在Up操作完了之后把ELF下载进去；要是板子里本来就有程序了，大家用/NoCODE这个参数只把符号加载进去就行，不用费事去重复下载代码。

　　3、注意软件复位和硬件复位差异

　　有些芯片如果只做软件复位的话，它和外面那个硬件reset引脚产生的复位效果是不一样的。外设、电源域、调试模块，还有看门狗和BootROM的状态，有时候会留下一部分，有时候又会重新初始化。TRACE32应对软件复位的时候也有它自己的一套处理方式，比如软件复位发生的时候调试器要不要停机，或者要不要让它继续跑，这些情况都会影响到大家最后看到的复位后的状态。

　　二、TRACE32复位后程序入口跳转异常怎么办

　　要是复位完发现入口跳转不对劲，常见的样子就是PC寄存器没有停在我们想让它停的入口，或者程序自己跑到异常向量里去了，又或者是main函数的断点根本拦不住，源码窗口里面的内容也不跟着变，甚至一复位就直接死机进死循环了。碰到这种麻烦事，调试人员得先去瞅瞅复位之后的PC和SP变成什么样了，接着再去看看向量表、启动文件、链接地址，还有Bootloader的跳转逻辑。

　　1、检查复位向量和入口地址

　　对于很多MCU来说，复位之后CPU都会去向量表里读出初始的SP和reset handler地址。就像平时经常看到的Cortex-M启动方式那样，向量表的开头地方放着初始的栈指针和复位的入口地址；要是这个向量表自己发生偏移了，那读取的位置肯定也跟着变了。这种问题在调试器里面看的话，就是PC寄存器莫名其妙跳到一个很怪的地址上，或者直接就报HardFault错误了。

　　2、检查链接地址和实际运行地址

　　入口跳转不对劲还有一个经常遇到的原因，就是ELF文件的链接地址和程序真正在里面跑的运行地址不一样。打个比方，应用程序在链接的时候写的是0x08020000，可是复位之后CPU还是死板地去0x08000000找向量；或者是Bootloader本来应该带着跳到应用的入口去，结果VTOR、栈指针还有跳转函数地址这些东西全都没切过去。

　　3、检查Bootloader跳转和中断向量切换

　　在Bootloader准备往应用程序跳的时候，光改一个PC寄存器是不够的。一般情况下，我们还得把应用的MSP设好，把向量表的基地址更新一下，把中断关掉或者重新配一遍，连Cache和外设的状态也得处理好。如果这些事情漏掉没做，那调试人员在TRACE32里看到的情况就是，入口虽然好像是跳过去了，但是一眨眼又报错了，要么跑飞了，要么直接进了默认的中断里面。

　　三、TRACE32复位调试还要注意哪些检查

　　我们在调复位流程的时候，最让人头疼的就是脚本不稳定。今天自己手动点点还能跑，明天换个同事来用就歇菜了。所以这边建议把复位的方式、加载的办法、符号怎么加、断点怎么挂，还有入口怎么确认这些事情，全都写到.cmm脚本文件里去，往后每次都按这一套一样的顺序来跑，这样就能少一点因为人工操作不一样带来的古怪问题。

　　1、先确认CPU是否真正停住

　　复位做完以后，大家不要一上来就认定是程序写错了，调试人员得先看一眼TRACE32屏幕底下的状态栏、看看PC、SP还有当前处理的Core。要是在多核芯片里面，大家还得认准现在停下来的到底是哪个Core。因为有些芯片在复位以后，只有主核被放开了，从核还被关在reset或者clock gated状态里，这个时候你去瞧从核的入口，那看起来肯定是不正常的。

　　2、不要把符号问题误判成跳转异常

　　有的时候程序入口其实已经跳到正确的地方了，但是TRACE32上面显示不出函数的名字，也找不到对应的源码行，看着就像是“跳错了”一样。这种情况多半是因为ELF的版本没对上、符号加载的地址写错了、源码文件的路径给丢了，或者大家光加载了镜像，没把里面的调试信息一起加进来。

　　3、把复位后的关键现场记录下来

　　复位完了以后，这边建议大家把PC、SP、状态寄存器、向量表地址、入口函数地址，还有现在的异常状态都固定记在一个小本本上。特别是一复位就直接报错的那些情况，调试人员得先去瞅瞅异常入口、Fault状态寄存器，还有栈里面存着的返回地址，可别一出问题就手忙脚乱地直接去重新复位。

　　总结

　　关于TRACE32复位流程怎么配置，这里面的核心其实就是先搞清楚SYStem.Up和Attach分别该在什么情况下用。然后再按照目标板子的启动规律，把让它运行这些动作排好顺序。至于TRACE32复位后程序入口跳转异常怎么办，大家重点去查查PC、SP、复位向量、向量表基地址、链接地址、Bootloader跳转，还有ELF符号到底能不能合得上。我们在真正去排查的时候，可不能只傻傻地盯着main函数的断点，必须要从reset vector、startup、栈指针、向量表，还有Bootloader跳转的这一整条链路上一步一步地去抠，这样大家才能辨别明白这到底是复位没配好，还是入口地址算错了，又或者是符号没显示出来的问题。