在调试启动代码、中断服务程序、任务切换或者底层外设驱动的时候，光盯着C语言层面的变量往往判断不出真正的问题，直接观察寄存器窗口反而能更快抓住线索。Green Hills MULTI调试器支持多种处理器架构和连接方式，在配合硬件探针时，不仅能设置断点、读写内存，也可以实时查看通用寄存器、程序计数器、堆栈指针、状态寄存器和部分外设寄存器。按照官方资料的说明，成功连接目标之后，通过读写寄存器来验证调试链路是否正常，本身就是一个很基础的检查手段。

　　一、Green Hills寄存器窗口怎么快速查看

　　在着手查看寄存器之前，需要先确认目标板已经进入调试状态并且处于暂停状态。如果程序还在全速运行，寄存器窗口里的值就可能一直跳个不停，不能直接拿来分析；即便符号文件还没有加载，寄存器依然可以显示，只不过此时不容易把数值和源码位置对应起来。

　　1、打开寄存器视图

　　进入MULTI Debugger界面之后，从窗口菜单中找到Registers或者名字类似的Processor Registers视图。虽然不同芯片支持包在菜单命名上会有些差别，但这个视图一般都会按照处理器核心，把通用寄存器、PC、SP、LR、状态寄存器和一些特殊寄存器分组列出来，查找起来比较方便。

　　2、在断点处观察寄存器快照

　　通常先在main函数、异常入口或者需要调试的驱动函数上打一个断点，让程序跑起来并停住以后，再去打开寄存器窗口。这时候PC的值可以说明程序究竟停在了哪一条指令上，SP则能反映出当前堆栈的大致位置，而状态寄存器里的标志位则可以帮助判断中断是否被屏蔽、处理器当前处于哪种特权等级或者是否进入了异常状态。

　　3、结合反汇编窗口一起分析

　　单看寄存器还不够，最好把Disassembly反汇编窗口也一并打开。当按指令单步执行时，直接观察参与运算的那几个寄存器有没有按照设计好的逻辑在变化，这对于调试启动文件、高度优化的汇编代码或者内联函数尤其管用。在有优化选项的代码里，源码行和汇编指令经常不再是一一对应的关系，以反汇编和寄存器实际变化为准，会可靠很多。

　　4、自定义外设寄存器视图

　　一部分目标芯片支持专用的Register Viewer或者外设寄存器描述文件，Green Hills的相关资料也提到，MULTI可以为用户定制的设备动态创建寄存器查看窗口，并且能显示每个位的含义。在调试GPIO、定时器、CAN、SPI这类外设时，直接看带有位域说明的视图，比起盯着一串十六进制地址去猜，要直观得多。

　　二、Green Hills寄存器变化过程怎么跟踪

　　寄存器窗口呈现出来的只是某一个时刻的静态切片，要想捕捉寄存器变动的全过程，就要把单步执行、条件断点以及Trace或TimeMachine这类历史记录功能配合起来使用。

　　1、利用单步执行观察连续变化

　　在关键代码之前设好断点，程序停住之后，用Step Into或Step Instruction模式逐条指令地向前推进，每走一步就扫一眼PC、SP还有那些相关的通用寄存器，看看它们是按照预期逐步更新，还是在某一步突然跳到错误的位置。如果窗口刷新不及时，可以先让目标保持暂停，再手动刷新寄存器视图。

　　2、设置条件断点捕捉特定场景

　　当怀疑某个寄存器只在特殊路径下才会出现异常时，就可以在中断入口、任务调度函数或者驱动初始化代码处设一个条件断点，让程序只在满足设定条件的时刻停下来，然后再去检查寄存器现场，这样比不断重复手工操作要高效得多。

　　3、借助Trace List回看执行历史

　　如果需要回过头去分析函数级别甚至汇编级别的执行过程，就可以用到TimeMachine或Trace相关的功能。NXP公司关于Green Hills工具的培训资料中也提到过，可以在Debugger窗口的Time Machine菜单中打开Trace List，回溯函数级和汇编级的执行记录，对于剥离复杂的时序问题很有帮助。

　　4、记录关键寄存器在修改前后的对比值

　　排查启动失败、异常跳转或者中断返回出错这类故障时，建议把修改前后PC、SP、状态寄存器和异常相关寄存器的值都摘录下来，而不是只截一张最后的报错画面。如果缺少前一次的正常值，就很难判断错误到底是从哪一步开始蔓延开的。

　　三、Green Hills寄存器值异常怎么排查

　　寄存器窗口里看到的值明显不对劲时，先不要急着认定是程序逻辑写错了，也可能是调试显示、目标连接状态或者当前上下文选取的问题。

　　1、确认当前选中的核心和任务

　　在多核系统里，寄存器窗口展示的是当前被选中的那个核心的内容；如果是在RTOS环境下，还要进一步确认当前正处于哪个任务的上下文中。要是核心或者任务选错了，寄存器中的数值很自然就会和预想的代码位置对不上。

　　2、确认目标是否确实已经停止

　　目标还在运行时去读寄存器，窗口里的数值可能会不停地抖动，根本无法拿来分析。正确的顺序是先让目标暂停，再查看寄存器；如果暂停之后值依然怪异，再结合Memory窗口和反汇编窗口一起校对，判断到底是程序真的把寄存器改坏了，还是调试器读取出的数据有误。

　　3、注意优化和内联带来的干扰

　　在高优化等级的代码中，很多变量可能被编译器直接放到寄存器里，也有一些变量会被完全优化掉。此时源码行和实际执行的汇编指令就不再一一匹配，调试时就要把注意力更多地放在反汇编窗口和寄存器的实际变化上，而不是执着于源码里的某一行。

　　4、验证探针和目标之间的连接稳定性

　　一旦出现寄存器读写失败、数值随机跳变或者调试连接频繁断开的情况，就要依次检查调试线缆是否牢固、目标板供电是否稳定、复位信号是否正常，以及JTAG或DAP接口的通信速率是否过于激进。Green Hills Probe手册也建议，在怀疑连接异常时先用读写寄存器和内存的方式来验证链路是否可靠，再继续深入排查其他问题。

　　总结

　　总结来看，在Green Hills MULTI中查看寄存器状态，通常先让目标进入调试并暂停，再打开Registers窗口观察PC、SP、状态寄存器和通用寄存器；想要跟踪寄存器变化过程，则可以结合单步、条件断点以及Trace List和TimeMachine等功能。如果寄存器数值明显异常，重点核对当前选中的核心、任务上下文、目标是否真正暂停、编译优化造成的影响以及探针连接的稳定性，这样就能把大部分显示问题限定在信号链路、配置或观察方法本身，而不是一上来就怀疑程序逻辑有错。