1. 项目概述从芯片手册到实战经验如果你正在基于Cortex-M4F内核比如TI的TM4C123x系列开发嵌入式产品那么异常处理和电源管理这两个话题绝对是你绕不开的“硬骨头”。芯片手册里那些关于故障状态寄存器、死锁、WFI/WFE指令的描述往往读起来冰冷而抽象仿佛在说另一个世界的事情。但当你真正把代码烧录进板子面对一个毫无征兆的死机或者电池电量在待机时飞速耗尽时你就会深刻体会到理解这些机制不是选修课而是生存技能。我经历过不少这样的时刻一个看似简单的内存越界最终演变成难以追踪的硬件故障一个为了省电而设计的睡眠逻辑反而让设备再也唤不醒。这些教训让我明白仅仅知道“是什么”远远不够必须深挖“为什么”以及“怎么用”。本文的目的就是把我这些年踩过的坑、总结的经验结合Cortex-M4F的官方机制进行一次系统性的梳理和实战化解读。我们将不仅会拆解那些寄存器位和指令更会探讨它们在实际项目中的应用场景、配置陷阱和调试技巧。无论你是正在评估M4F芯片的架构师还是在一线调试的工程师希望这些内容能帮你构建起更稳固、更高效的系统。2. 异常处理机制深度解析与实战配置异常处理是Cortex-M4F内核的“免疫系统”。一个健壮的系统不仅要能处理外部中断如按键、串口数据更要能妥善应对内部发生的各种错误如访问非法地址、执行未定义指令。M4F的嵌套向量中断控制器NVIC和系统控制块SCB共同构建了一套精细的异常处理体系。2.1 异常优先级与抢占逻辑不仅仅是“谁先谁后”异常优先级是理解一切的基础。Cortex-M4F的异常包括中断优先级是可编程的数值越小优先级越高。但这里有几个关键细节手册里可能一笔带过实践中却至关重要。首先固定优先级异常。复位Reset、不可屏蔽中断NMI和硬件故障HardFault拥有固定的、最高的优先级。这意味着当系统发生严重错误如执行了非法指令触发硬件故障时无论当前正在处理哪个中断处理器都会立即抢占转去执行HardFault_Handler。这是系统最后的“安全网”。其次优先级分组。NVIC支持优先级分组将8位优先级字段分为“抢占优先级”和“子优先级”。只有更高“抢占优先级”的异常才能打断当前正在处理的异常相同“抢占优先级”的异常则比较“子优先级”子优先级高的先执行但不能相互打断。合理配置分组对于构建复杂的实时系统至关重要。例如在一个电机控制系统中你可以将过流保护的异常设为最高抢占优先级确保它能立即响应而将通讯中断设为较低的抢占优先级但较高的子优先级保证通讯的实时性又不影响安全关键任务。注意一个常见的误解是所有异常都能相互抢占。实际上如果两个异常的抢占优先级相同后发生的异常会进入挂起状态等待当前异常处理完毕。如果挂起时间过长可能触发超时或其他逻辑错误。2.2 故障分类与状态寄存器精准定位“案发现场”当系统跑飞最让人头疼的就是定位问题根源。Cortex-M4F将可配置的故障细分为三类并提供了对应的状态寄存器这就像给系统装上了“黑匣子”。存储器管理故障MemManage Fault通常由MPU存储器保护单元触发。例如用户态程序试图访问内核态内存或者向只读区域执行写操作。相关的状态寄存器是MFAULTSTAT故障地址寄存器是MMADDR。总线故障Bus Fault发生在处理器通过总线访问存储器或外设时。常见原因包括访问了不存在的物理地址、设备未就绪、或违反了设备访问规则如向只读的设备控制寄存器写数据。状态寄存器是BFAULTSTAT地址寄存器是FAULTADDR。用法故障Usage Fault由指令执行错误引起。例如执行了未定义的指令、尝试在非Thumb状态下执行ARM指令Cortex-M只支持Thumb、非对齐的内存访问当配置为禁止时、除零操作当配置为触发故障时。状态寄存器是UFAULTSTAT它没有独立的地址寄存器。硬件故障HardFault是上述所有可配置故障的“总兜底”。当发生一个总线故障但总线故障处理程序本身被禁用未使能时这个故障就会升级Escalation为硬件故障。这是故障处理中一个非常关键的概念。实战心得如何利用故障寄存器调试仅仅知道寄存器名字没用关键是怎么用。在HardFault_Handler中第一件事就是读取SCB-CFSR组合故障状态寄存器它包含了MFAULTSTAT, BFAULTSTAT, UFAULTSTAT。通过解析其中的标志位你可以快速判断故障类型。例如如果CFSR的MMARVALID位为1说明MMADDR寄存器中保存了有效的故障地址这很可能是一个非法内存访问。你可以立刻将这个地址值通过调试器打印出来或者保存在一个全局变量中供后续分析。结合反汇编工具和内存映射图你就能定位到是哪一行C代码或对应的汇编指令试图访问这个非法地址。这个流程比漫无目的地单步调试要高效得多。2.3 死锁Deadlock与故障升级最危险的系统僵局死锁是异常处理机制中最严重的一种状态意味着处理器完全停止执行指令。根据手册描述当处理器正在执行NMI或硬件故障处理程序时如果再次发生一个硬件故障处理器就会进入死锁状态。这听起来有点绕我画个场景你就明白了假设你的HardFault_Handler函数里有一条指令不小心又访问了一个非法地址。在第一次硬件故障的处理过程中又触发了第二次硬件故障。由于硬件故障的优先级是固定的且处理器已经处于最高优先级的异常处理中它无法自己抢占自己来处理这个“新”的故障于是逻辑上陷入死循环硬件上表现为死锁。更棘手的是手册里提到的那个细节“如果死锁状态从NMI处理程序引发那么随后的NMI不会使处理器离开死锁状态。”这意味着即使你设计了看门狗Watchdog定时器其超时复位通常通过NMI或系统复位实现但如果死锁发生在NMI处理程序中连看门狗都可能失效系统将彻底“砖化”。避坑指南编写安全的异常处理程序异常处理程序应尽可能简单理想情况下HardFault_Handler和NMI_Handler中只做最必要的操作比如保存关键上下文、记录错误码、然后触发系统复位。避免在其中进行复杂的计算或内存访问。避免在异常处理程序中调用库函数很多标准库函数如printf,malloc本身不是可重入的并且可能引发新的故障。如果需要记录信息直接操作寄存器或使用事先分配好的静态缓冲区。启用栈溢出检测如果使用RTOS或复杂的多层调用栈溢出是引发连环故障的常见原因。Cortex-M4F的MPU可以配置栈保护区或者通过软件在栈顶放置魔数Magic Number并定期检查。设计最终的硬件复位通路除了看门狗考虑增加一个独立的硬件看门狗或者一个由外部定时器控制的复位电路作为系统恢复的最后手段。2.4 故障现场保护与堆栈分析当异常发生时处理器会自动将8个寄存器R0-R3, R12, LR, PC, xPSR压入当前使用的堆栈主堆栈MSP或进程堆栈PSP。这份压栈的数据是异常现场的第一手资料。然而手册中提到了一个极端但重要的情况“当进入一个总线故障处理程序时如果在堆栈入栈期间发生了一个总线故障该总线故障不会扩大到硬件故障。因此如果一个损坏的堆栈引起了一个故障即使该处理程序的入栈失败故障处理程序依然会执行。”这意味着如果因为堆栈指针SP本身指向了一个非法或只读的内存区域导致压栈动作本身触发总线故障这个故障会被特殊处理处理器会尝试跳过压栈步骤直接使用默认的MSP跳转到故障处理程序。此时你无法从堆栈中获取准确的现场信息因为压栈失败了。你的故障处理程序虽然运行了但运行在一个“堆栈内容损坏”的环境中非常脆弱。调试技巧如何应对堆栈损坏在HardFault_Handler开头检查LR的值进入异常时的LREXC_RETURN值可以告诉你之前使用的是MSP还是PSP以及是否使用了浮点寄存器。这有助于判断故障发生的上下文是线程模式还是Handler模式。直接读取MSP/PSP指针即使压栈失败SP指针本身可能还是有效的。你可以通过内联汇编直接读取MSP或PSP的值然后手动检查该地址附近的内存内容看看是否有规律的数据比如函数返回地址通常指向代码区。使用调试器检查Call Stack在发生故障时立即暂停调试器。虽然调用栈可能不完整但调试器通常能显示SP的当前值和附近内存的内容结合反汇编有时能推断出SP是如何被破坏的例如数组越界写穿了栈。3. 电源管理实战从睡眠模式到低功耗设计对于电池供电的物联网设备功耗就是生命线。Cortex-M4F提供了从芯片级睡眠模式到系统级外设时钟门控的多种功耗管理手段。理解并正确使用它们能将设备待机电流从mA级别降至μA级别。3.1 睡眠模式与深度睡眠模式内核与系统的休眠睡眠模式Sleep Mode和深度睡眠模式Deep Sleep Mode主要通过SYSCTRL寄存器中的SLEEPDEEP位来选择。它们的区别远不止名字上的“深度”二字。睡眠模式SLEEPDEEP 0仅停止处理器内核Cortex-M4F的时钟。所有外设如GPIO、UART、定时器的时钟依然在运行内存保持供电数据不丢失。唤醒速度极快通常只需几个时钟周期。这种模式适用于短暂空闲等待一个很快就会发生的中断比如等待一个软件定时器超时或一个GPIO边沿中断。深度睡眠模式SLEEPDEEP 1停止系统时钟包括大部分外设的总线时钟并可能关闭PLL和Flash存储器的电源。具体行为取决于芯片厂商的实现。在TI的TM4C系列中深度睡眠模式会关闭主振荡器和PLL使用低功耗的内部振荡器并可以配置Flash进入低功耗状态。唤醒需要重新启动PLL和稳定系统时钟因此延迟较长但功耗显著降低。配置选择建议追求极速唤醒响应时间10μs使用睡眠模式。例如处理高频的PWM信号或高速ADC采样中断。追求极低功耗待机电流100μA使用深度睡眠模式。例如传感器节点每小时采集一次数据并上传大部分时间在深度睡眠。折中方案许多芯片提供更细粒度的深度睡眠子模式。例如可以保持SRAM供电而关闭Flash这样唤醒后程序可以立刻从RAM运行省去了Flash上电的时间。3.2 进入睡眠的三种指令机制WFI, WFE, Sleep-on-Exit这是电源管理的核心操作每条指令背后都有其特定的使用哲学。3.2.1 WFI (Wait For Interrupt)WFI指令是最简单直接的睡眠命令。执行后处理器立即进入睡眠模式直到一个足够优先级的异常通常是中断发生并被NVIC处理时才会唤醒。特点行为确定。只要执行立刻睡觉。唤醒条件严格需处理中断。典型应用在简单的超级循环Super Loop中完成所有任务后执行WFI()进入睡眠等待下一个定时器中断到来开启新的工作周期。这是裸机系统最常见的低功耗实现方式。// 裸机系统主循环示例 int main(void) { SystemInit(); Peripheral_Init(); while(1) { // 1. 检查并处理所有任务标志位 if (timer_flag) { handle_timer(); timer_flag 0; } if (uart_rx_flag) { process_data(); uart_rx_flag 0; } // 2. 所有任务处理完毕进入睡眠等待中断 __WFI(); // 使用CMSIS标准库提供的 intrinsic 函数 } }3.2.2 WFE (Wait For Event)WFE指令的睡眠条件与一个内部的1位“事件寄存器”相关。执行WFE时处理器先检查该寄存器若为0则进入睡眠若为1则清零该寄存器并继续执行不睡眠。事件来源主要有两个1) 执行SEV发送事件指令2) 配置SEVONPEND位后任何新的中断挂起即使被禁用都会产生事件。特点行为依赖于历史状态。可以用来实现“事件驱动”的同步避免不必要的睡眠-唤醒开销。典型应用在多核系统中用于核间通信和同步。在一个RTOS中当任务队列为空时调度器可以执行WFE睡眠。当另一个任务或中断发布SEV一个新任务时处理器被唤醒检查队列并执行任务避免了轮询开销。3.2.3 Sleep-on-Exit这是一个配置位SLEEPEXIT而非指令。当此位置位且处理器从异常处理程序返回线程模式时它会自动再次进入睡眠模式而无需执行WFI或WFE。特点自动化程度高适合中断驱动的单任务系统。典型应用在极其简单的传感器应用中主程序线程模式可能什么都不做。所有工作都在中断服务程序ISR中完成如采集数据、发送数据。设置SLEEPEXIT后设备上电即睡眠中断到来时被唤醒执行ISRISR返回后自动再次睡眠实现了最低的软件复杂度与功耗。重要提示使用Sleep-on-Exit时必须确保所有必要的初始化都在中断服务程序或初始化代码中完成因为主线程可能根本没有机会运行。3.3 唤醒机制与系统恢复流程唤醒是睡眠的另一面一个设计不当的唤醒逻辑可能导致设备“睡死”。从WFI/Sleep-on-Exit唤醒核心条件是NVIC检测到一个优先级足够高、且被使能的异常。这里“足够高”指的是优先级高于当前被屏蔽的优先级由BASEPRI寄存器指定。唤醒后处理器会先进行现场恢复出栈然后直接跳转到对应异常的处理程序。从WFE唤醒除了上述异常条件还有一个关键机制SEVONPEND位。当此位置位时任何外设产生的中断即使这个中断在NVIC中被禁用未使能只要它从非挂起状态变为挂起状态就会触发一个内部事件唤醒处于WFE睡眠的处理。应用场景动态电源管理。假设一个设备有多个唤醒源按键、串口、RTC。在深度睡眠下你可以关闭大部分外设时钟以省电。当某个未被使能的中断源如按键按下产生信号时由于SEVONPEND的作用处理器会被事件唤醒。唤醒后在中断服务程序执行前你可以在PRIMASK屏蔽中断的短暂窗口内快速使能对应外设的时钟和NVIC中断然后再清除PRIMASK让正常的中断处理流程继续。这样外设只在需要时才上电进一步节省了功耗。系统恢复流程从深度睡眠唤醒比睡眠模式复杂。通常需要退出低功耗模式重新使能主振荡器如晶振。等待振荡器稳定可能需要数毫秒。重新配置PLL将系统时钟升频到工作频率。恢复Flash存储器的访问速度。最后才跳转到中断服务程序。这个流程通常由芯片的底层库函数或启动代码自动完成但作为开发者你需要关注其中耗时最长的步骤如晶振起振因为它决定了你的设备“从睡眠到能干活”的最短时间这对于需要快速响应的应用至关重要。3.4 低功耗设计实战经验与测量理论再好也要实测。以下是一些经过验证的低功耗设计技巧关闭无用外设时钟在进入深度睡眠前通过芯片的系统控制模块如TI的SYSCTL关闭所有不必要外设的时钟门控。这是最直接有效的省电方法。配置未使用的GPIO将未使用的GPIO引脚设置为输出低电平或输入带上拉/下拉避免引脚浮空产生漏电流。对于可能被意外触碰的引脚配置为输出模式更安全。动态调整系统时钟在不需要高性能时如处理低速通讯降低系统主频。功耗与频率大体呈线性关系。许多MCU支持运行在内部低速振荡器如32kHz上。使用停机Stop或待机Standby模式对于Cortex-M4F深度睡眠可能还不是最省电的模式。查阅你的具体芯片手册看是否支持更极端的停机模式关闭所有时钟仅保留部分寄存器和RAM或待机模式关闭所有电源仅依靠备份域维持RTC和少量寄存器。这些模式的唤醒源更有限通常只有RTC、外部复位、特定唤醒引脚但电流可低至微安甚至纳安级。功耗测量技巧使用高精度万用表串联在供电回路中测量电流。注意选择合适量程。观察波形使用示波器观察MCU的电源引脚或特定的“运行指示”GPIO引脚波形。可以清晰看到运行、睡眠、唤醒的电流变化周期。计算平均电流设备在不同状态全速运行、睡眠、发射、接收的电流和持续时间不同。根据你的应用场景计算一个工作周期内的平均电流这才是评估电池寿命的关键。4. Cortex-M4F指令集精要与高效编程Cortex-M4F支持Thumb-2指令集并加入了DSP扩展和单精度浮点单元FPU指令。理解这些指令的特性和适用场景能让你写出更高效、更紧凑的代码。4.1 指令集概览与分类思维面对手册中长长的指令表不要试图死记硬背。建立分类思维是关键。我们可以将指令分为几个大类类别主要功能典型指令应用场景数据传送在寄存器与存储器/寄存器间移动数据LDR/STR,LDM/STM,MOV变量加载、存储上下文保存算术运算加、减、乘、除等基本运算ADD,SUB,MUL,SDIV/UDIV计数器、地址计算、数学运算逻辑与移位位操作、移位AND,ORR,EOR,LSL,ASR掩码操作、位域提取、乘除2的幂优化比较与测试比较值并设置标志位CMP,CMN,TST,TEQ条件判断、循环控制分支与控制改变程序流B,BL,BX,CBZ,IT函数调用、循环、条件执行饱和与SIMDDSP相关操作QADD,SADD16,UADD8音频处理、图像处理、控制算法浮点运算单精度浮点计算VADD.F32,VMUL.F32,VDIV.F32电机FOC、姿态解算、复杂滤波4.2 高效编程技巧与指令选择1. 利用条件执行IT指令减少分支Thumb-2指令集支持ITIf-Then块使得其后的1-4条指令可以条件执行。这能有效减少短小条件判断带来的分支跳转提升流水线效率。; 传统方式分支跳转 CMP R0, #10 BNE not_equal ADD R1, R1, #1 not_equal: ... ; 优化后条件执行 CMP R0, #10 ITTTE EQ ; If-Then-Then-Then-Else (根据条件设置后4条指令) ADDEQ R1, R1, #1 ; (EQ) R1 R1 1 MOVEQ R2, #0xAA ; (EQ) R2 0xAA ... ; (EQ) 其他操作 MOVNE R2, #0x55 ; (NE) R2 0x552. 灵活使用多寄存器加载/存储LDM/STMLDM和STM指令能一次性加载或存储多个寄存器特别适用于函数入口/出口的上下文保存与恢复效率远高于多条单独的LDR/STR。; 函数入口保存 R4-R11, LR PUSH {R4-R11, LR} ; 函数出口恢复 POP {R4-R11, PC} ; 将LR弹出到PC实现函数返回3. 善用硬件除法器与浮点单元Cortex-M4F集成了硬件除法器SDIV/UDIV和单精度FPU。对于整数和浮点除法应始终使用硬件指令避免调用软件库函数性能有数量级的提升。编译器通常会自动优化但确保编译选项已开启硬件支持如-mfpufpv4-sp-d16 -mfloat-abihard。4. DSP扩展指令加速算法对于常见的数字信号处理操作如饱和加法、SIMD单指令多数据操作要善用DSP扩展指令。QADD/QSUB进行饱和加减法结果不会溢出环绕对于音频采样等处理非常安全。SADD16一条指令同时完成两个16位有符号数的加法相当于2倍的加速。SMULBB/SMULTT16位乘16位得到32位结果是滤波器如FIR中乘积累加运算的核心。5. 理解加载/存储的寻址模式LDR/STR指令支持丰富的寻址模式偏移寻址、前索引寻址、后索引寻址。理解它们能生成更高效的代码。LDR R0, [R1, #4]从地址R14加载R1不变。LDR R0, [R1, #4]!前索引从R14加载然后R1 R1 4。LDR R0, [R1], #4后索引从R1加载然后R1 R1 4。 后索引模式在遍历数组时特别有用。4.3 浮点单元使用注意事项启用FPU能极大提升浮点运算速度但需要注意以下几点上下文保存当发生中断或任务切换时如果使用了FPU寄存器S0-S31, FPSCR需要额外保存这些寄存器。Cortex-M4F提供了Lazy Stacking机制可以延迟保存直到真正使用FPU时才进行但RTOS或你自己的上下文切换代码需要支持这个特性。编译选项必须使用正确的编译选项。-mfloat-abihard硬浮点ABI会让编译器直接使用FPU寄存器传递浮点参数效率最高。softfp则用整数寄存器传递在函数内使用FPU。soft则是纯软件浮点库。性能与精度FPU是单精度的符合IEEE 754标准。但对于某些需要高精度或双精度的科学计算仍然不够需要软件库支持。同时要注意非规格化数Denormal的处理速度很慢在实时性要求高的场合应避免产生或将其刷新为零。初始化系统启动后需要使能FPU。通常是在SystemInit()函数中设置CPACR寄存器的相关位。// 使能Cortex-M4F FPU void FPU_Enable(void) { SCB-CPACR | ((3UL 10*2) | (3UL 11*2)); // 使能CP10和CP11协处理器即FPU __DSB(); // 数据同步屏障确保指令生效 __ISB(); // 指令同步屏障清空流水线 }5. 常见问题排查与调试技巧实录理论结合实践最后这部分分享一些我在调试Cortex-M4F系统时遇到的典型问题及解决方法。5.1 系统莫名进入HardFault这是最常见也最令人头疼的问题之一。按照以下步骤排查可以系统性地定位问题。检查LR链接寄存器的值在HardFault_Handler中首先读取LR的值。如果LR的位2为0表示异常发生时使用的是MSP主堆栈如果为1则使用的是PSP进程堆栈。这能帮你判断是操作系统任务出错还是底层中断/异常出错。读取CFSR可配置故障状态寄存器这是最重要的步骤。SCB-CFSR的各个位指明了故障类型。IACCVIOL(位0): 指令取指违规。PC指针跑飞到了非代码区如数据区。DACCVIOL(位1): 数据访问违规。通常是野指针或数组越界。MUNSTKERR(位3) /MSTKERR(位4): 异常返回时出栈/入栈错误。强烈指向堆栈溢出。IBUSERR(位8) /PRECISERR(位9) /IMPRECISERR(位10): 总线错误。访问了不存在的地址或设备未响应。UNDEFINSTR(位16): 未定义指令。可能是数据损坏被当成指令执行或编译器/链接器错误。读取故障地址寄存器如果MMARVALID或BFARVALID位被置位那么MMADDR或FAULTADDR寄存器中就保存了导致故障的确切内存地址。在map文件或调试器中查找这个地址属于哪个变量或函数是定位问题的直接证据。回溯调用栈即使堆栈可能部分损坏尝试手动分析堆栈内容。从当前MSP或PSP指向的地址开始向上查看内存。在ARM架构中异常发生时压栈的PC值指向了触发异常的那条指令的下一条指令。找到这个PC值就能定位到出问题的函数。5.2 低功耗模式下无法唤醒设备睡下去就醒不来问题可能出在睡眠配置或唤醒源上。确认睡眠模式检查SLEEPDEEP位是否按预期设置。用示波器测量主时钟引脚看进入睡眠后时钟是否停止。检查唤醒源配置中断使能了吗确保用来唤醒的中断在NVIC中是使能的。外设中断使能了吗例如你想用UART RX中断唤醒除了NVIC还要使能UART本身的中断控制位。引脚配置正确吗对于GPIO外部中断唤醒引脚必须配置为输入模式并且上下拉电阻状态要匹配你的触发信号如按键按下是低电平则应启用上拉电阻。中断标志清除了吗在进入睡眠前确保相关的外设中断标志已被清除否则可能一进入睡眠立刻又被挂起的中断唤醒。检查唤醒后的时钟从深度睡眠唤醒后系统时钟可能从低速内部振荡器开始运行。如果你的初始化代码或中断处理程序开头假设系统时钟已经是高速状态比如进行微秒级的延时可能会导致程序卡死。确保唤醒后的初始化流程正确恢复了系统时钟配置。使用调试器许多现代调试器支持“连接时保持复位”或“附着到运行中的芯片”功能。你可以在设备睡眠后尝试连接调试器然后单步执行唤醒后的第一条指令观察程序流。5.3 使用FPU后计算结果异常或进入异常FPU未使能这是最可能的原因。确认在main()函数或系统初始化早期调用了FPU使能函数。编译选项不一致确保整个项目包括所有库文件都使用相同的浮点ABI设置-mfloat-abihard。如果主程序用硬浮点编译而某个库文件是用软浮点编译的在链接时可能不会报错但运行时调用约定混乱必然出错。上下文保存不完整如果你在RTOS中使用了FPU并且任务中进行了浮点运算那么任务切换时必须保存/恢复FPU寄存器S0-S31和FPSCR。检查RTOS的移植文件如port.c是否正确实现了FPU上下文切换。Lazy Stacking机制可以帮忙但需要正确配置。非规格化数当浮点数运算结果非常接近于零时可能会产生非规格化数。处理这类数的速度极慢且在某些配置下可能触发异常。可以在FPU配置寄存器中设置FPSCR的FZFlush-to-Zero位将非规格化数直接当作零处理以提升性能和确定性。调试这类问题可以尝试在首次使用浮点数的代码前设置一个断点单步执行并观察FPU控制寄存器FPSCR的值以及浮点运算指令执行后目标寄存器的值是否符合预期。