1. 异常处理机制总览从概念到实践在嵌入式开发尤其是基于ARM Cortex-M内核的项目里异常处理机制是系统稳定性和实时性的基石。很多开发者尤其是刚接触RTOS或复杂外设交互的朋友常常觉得中断配置好了程序能跑起来就万事大吉。但当你遇到一个系统在某个特定操作下“死得不明不白”或者某个高优先级任务总是被意外打断时才会深刻体会到不理解异常处理的底层逻辑调试工作就如同在黑暗中摸索。简单来说异常Exception是处理器对内部或外部事件的响应机制它打断了正常的程序流。中断IRQ是异常的一种通常由外设触发。这套机制的价值在于它让CPU能够高效地处理异步事件比如按键按下、数据接收完成、定时器溢出甚至是程序执行出错比如访问了非法内存地址。在Cortex-M架构中这套机制被设计得非常精巧和统一从简单的裸机程序到复杂的实时操作系统如FreeRTOS、Zephyr都构建在这套基础之上。以TI的CC13x2/CC26x2这类无线MCU为例它们内置了复杂的射频、加密和低功耗管理模块异常和事件的处理直接关系到通信的实时性、功耗控制的精确性以及系统崩溃后的恢复能力。如果你只停留在调用HAL_NVIC_SetPriority和HAL_NVIC_EnableIRQ的层面那么当遇到HardFault_Handler时你很可能无从下手。本文将带你深入Cortex-M异常处理的细节并结合CC13x2/26x2的事件路由机制让你不仅知道如何配置更明白背后的“为什么”以及在实际项目中如何避坑。2. Cortex-M异常类型深度解析ARM Cortex-M将异常进行了系统化的分类每种类型都有固定的编号向量号、优先级和处理程序。理解它们是进行有效调试和系统设计的前提。2.1 核心系统异常这些异常由内核自身定义和管理是系统运行的基础。复位Reset 向量号1这是优先级最高-3的异常。它不仅仅是上电启动任何形式的复位看门狗复位、软件复位、引脚复位都会触发。触发后处理器会从向量表的第一个条目地址0x00000000加载初始栈指针MSP从第二个条目地址0x00000004获取复位处理程序的地址并开始执行。此时处理器处于特权线程模式。一个常见的误区是认为复位处理程序就是main()函数实际上在进入main()之前通常还有一段由编译器提供的启动代码Startup Code负责初始化.data段已初始化全局变量、.bss段未初始化全局变量并设置系统时钟。硬故障Hard Fault 向量号3这是所有故障的“最后防线”优先级固定为-1。当其他可配置优先级的故障处理程序如总线故障、用法故障被禁用或者故障处理程序自身又发生了故障时错误就会“升级”为硬故障。例如如果你的UsageFault_Handler没有使能此时执行了一条未定义的指令就会直接触发Hard Fault。它是不可屏蔽的意味着一旦发生处理器必须响应。在调试中HardFault是最常见的“死机”原因之一分析其状态寄存器HFSR是定位问题的关键第一步。总线故障Bus Fault 向量号5当处理器访问一个无效的或受保护的内存地址时触发。它可以进一步分为精确总线故障能精确定位到导致故障的指令。例如尝试向只读的Flash区域写入数据。不精确总线故障故障原因与当前执行的指令不同步通常与写缓冲Write Buffer有关。比如DMA正在向一个非法地址写入数据而CPU在稍后的指令流中才感知到这个错误。在CC13x2上访问一个已掉电的外设域如AUX域在MCU深度睡眠时也可能导致总线故障。用法故障Usage Fault 向量号6由非法使用处理器指令或架构定义引起常见原因包括执行了一条未定义的指令例如在Cortex-M4上尝试执行浮点指令而未使能FPU。尝试进行非对齐的内存访问在Cortex-M3/M4上默认是非对齐访问会触发故障但可以配置。执行BX或BLX指令时目标地址的LSB最低有效位不是1Thumb指令要求。异常返回时EXC_RETURN值非法。除零操作需在配置控制寄存器中使能陷阱。实操心得在项目初期强烈建议在调试配置中使能所有可配置的故障异常BusFault, UsageFault。这样当发生错误时你会得到一个更精确的故障类型比如明确的UsageFault而不是一个笼统的HardFault这能极大缩短问题定位时间。在CC26x2的SysConfig或SDK初始化代码中通常有相应的函数来配置这些故障处理。2.2 软件可触发的系统异常这类异常为操作系统和复杂应用提供了基础服务。SVCallSupervisor Call 向量号11由SVC指令触发。这是实现系统调用SysCall的基石。在RTOS中用户态任务通过执行SVC指令通常被封装成类似SVC 0的API陷入内核态请求操作系统服务如创建任务、分配内存。因为它是同步异常由明确指令触发其异常返回地址精确指向SVC指令的下一条指令便于内核进行参数解析和上下文管理。PendSVPendable Service Call 向量号14可挂起的系统服务请求。它是异步的通过向中断控制状态寄存器ICSR的PENDSVSET位写1来触发。它的关键特性是优先级可配置为最低。在RTOS中上下文切换Context Switching通常发生在PendSV异常中。为什么不用SysTick直接切换因为SysTick中断可能打断某个关键的系统调用。策略是SysTick中断触发后仅设置一个“需要切换”的标志然后手动触发一个PendSV异常。由于PendSV优先级最低它会等到所有其他中断包括SysTick自身都处理完毕后才执行实际的上下文切换任务从而保证了中断响应的实时性又实现了任务的平滑切换。SysTick系统节拍器 向量号15由系统定时器归零时触发。它是RTOS的心跳为任务调度提供时间基准。在裸机程序中也常用来实现精准延时或超时判断。它的中断服务程序ISR必须尽可能短小高效因为它的触发频率很高通常是1ms或10ms一次。2.3 外部中断IRQ向量号从16开始具体数量由芯片厂商定义。在CC13x2/CC26x2上有数十个IRQ对应着UART、SPI、定时器、射频核心等各个外设。它们是异步的可以随时发生。NVIC嵌套向量中断控制器负责管理所有IRQ的使能、禁用、优先级和挂起状态。这是开发者最常打交道的一部分。3. 异常处理的基石向量表与优先级3.1 向量表Vector Table详解向量表本质上是一个函数指针数组存储在内存的起始区域默认在0x00000000。每个条目4字节对应一个异常处理函数的入口地址。初始SP值 - 0x00000000 复位向量 - 0x00000004 NMI向量 - 0x00000008 硬故障向量 - 0x0000000C ...以此类推... IRQ0向量 - 0x00000040 IRQ1向量 - 0x00000044 ...关键点LSB必须为1Cortex-M只执行Thumb指令因此所有异常处理函数的地址最低位必须是1。编译器如GCC的-mthumb选项和链接脚本通常会处理好这一点。当你手动指定一个函数为中断服务程序时需要确保其地址符合这个要求通常使用__attribute__((interrupt))或#pragma vector等编译器扩展属性即可。向量表重定位通过设置VTORVector Table Offset Register寄存器可以将向量表移动到RAM或其他Flash地址。这在以下场景非常有用固件升级/IAPBootloader和Application有各自的向量表。跳转到Application前需要将VTOR设置为Application向量表的起始地址。动态更改中断服务程序将向量表放在RAM中允许在运行时修改某个IRQ的入口函数。CC13x2/CC26x2的注意点VTOR地址必须512字节对齐。在TI的驱动库中通常由启动文件或Startup函数负责初始化VTOR。3.2 异常优先级与嵌套规则优先级是决定异常处理顺序的核心。数字越小优先级越高。Cortex-M支持可编程优先级。固定优先级复位-3最高硬故障-1 这意味着即使你将某个IRQ的优先级设为0它的优先级也永远低于硬故障。可编程优先级 对于IRQ和大部分系统异常如SVCall、PendSV、SysTick其优先级可以通过NVIC的IPRInterrupt Priority Register寄存器组进行配置。在CC13x2/26x2上优先级范围通常是0-7使用3个位0是默认优先级。优先级分组Priority Grouping这是NVIC的一个高级功能用于在抢占优先级Group Priority和子优先级Subpriority之间划分优先级位。它通过SCB-AIRCR寄存器的PRIGROUP字段配置。抢占优先级决定中断是否可以嵌套。高抢占优先级的中断可以打断低抢占优先级的中断。子优先级当多个中断同时 pending 且抢占优先级相同时子优先级高的先执行。如果抢占和子优先级都相同则比较硬件中断编号IRQn编号小的优先。例如设置PRIGROUP4表示将8级优先级3位的高4位用作抢占优先级不这里需要理解PRIGROUP的值定义了从最高有效位MSB开始有多少位用于抢占优先级。对于支持8级优先级的设备如果PRIGROUP1则表示使用1位2级作为抢占优先级剩余2位4级作为子优先级。这个功能在复杂的实时系统中用于精细控制中断嵌套行为但在许多应用中直接使用简单的优先级数值不分组就已足够。嵌套与抢占流程处理器正在执行主程序线程模式或一个低优先级的中断服务程序ISR。一个更高优先级的中断发生状态变为挂起Pending。处理器立即在完成当前指令后响应将当前上下文PC, xPSR, R0-R3, R12, LR压入当前使用的栈MSP或PSP这个过程称为“压栈”Stacking。处理器从向量表中取出高优先级ISR的地址并跳转执行同时将LR更新为一个特殊的EXC_RETURN值。高优先级ISR执行完毕执行BX LR或类似的返回指令。处理器识别到EXC_RETURN进行“出栈”Unstacking恢复之前的上下文。如果此时有另一个同优先级或更低优先级的中断在挂起则处理器会直接跳转到它的ISR尾链Tail-Chaining省去一次出栈和压栈的开销提升效率。如果没有其他挂起的中断则返回到被打断的程序继续执行。4. 异常进入与返回的底层过程理解处理器在异常发生和返回时具体做了什么对于调试栈溢出、分析HardFault原因至关重要。4.1 异常进入压栈与上下文保存当异常发生时假设不是尾链或晚到异常处理器会自动将8个寄存器压入当前活跃的栈MSP或PSP。这8个寄存器构成了一个标准的“异常栈帧”。栈地址递减保存的内容说明SP-0x1CxPSR程序状态寄存器包含执行状态、中断号等SP-0x18PC返回地址即被中断指令的下一条指令地址SP-0x14LR链接寄存器此时被自动更新为EXC_RETURN值SP-0x10R12临时寄存器SP-0x0CR3通用寄存器SP-0x08R2通用寄存器SP-0x04R1通用寄存器SP-0x00R0通用寄存器为什么只保存R0-R3, R12, LR, PC, xPSR这是ARM架构调用标准AAPCS的一部分。在C语言函数调用中R0-R3用于传递参数R12是临时寄存器LR是返回地址。ISR本身也是一个C函数编译器会假设ISR函数如果需要使用R4-R11它会负责在函数开头将它们压栈Prologue在函数结尾弹出Epilogue。这种硬件自动保存软件保存结合的方式实现了效率和灵活性的平衡。EXC_RETURN值这是一个关键魔术数字如0xFFFFFFF1, 0xFFFFFFF9, 0xFFFFFFFD。LR被设置为此值它编码了返回时需要的信息返回后使用MSP还是PSR。返回后处于线程模式还是处理器模式。返回时使用的栈帧是基本栈帧还是扩展栈帧对于带FPU的Cortex-M4/M7。4.2 异常返回出栈与状态恢复异常返回不是通过普通的MOV PC, LR而是通过将EXC_RETURN值加载到PC来触发。处理器检测到这个特殊值会启动异常返回序列从栈中弹出之前保存的8个寄存器R0-R3, R12, LR, PC, xPSR。根据EXC_RETURN的值恢复正确的栈指针SP和处理器模式。从PC恢复执行。尾链优化如果当前ISR退出时已经有另一个已挂起且符合条件的异常在等待处理器会跳过“出栈-压栈”的完整过程直接进行向量获取跳转到下一个ISR。这节省了大量时间对于频繁发生的中断如SysTick性能提升显著。晚到异常如果在为异常A压栈的过程中一个更高优先级的异常B发生了处理器会立即转向处理异常B。由于压栈操作已经保存了异常A发生前的现场而这个现场对于异常B也是有效的因为B打断了A的压栈过程但A的ISR还未开始执行所以压栈操作会继续完成然后直接去执行异常B的ISR。这是一种硬件优化保证了最高优先级中断的响应延迟最小。5. 故障处理实战从触发到调试故障处理是嵌入式系统稳定性的最后一道防线。当程序跑飞、访问非法内存时故障处理机制被激活。5.1 故障状态寄存器定位问题的“黑匣子”当发生总线故障、用法故障或硬故障时相关的状态寄存器会记录下故障原因。这是调试的第一手资料。CFSR可配置故障状态寄存器这是一个组合寄存器包含UFSR用法故障状态寄存器记录除零、未对齐访问、非法指令、非法状态等。BFSR总线故障状态寄存器记录预取失败、存储访问失败、栈错误等。MMFSR内存管理故障状态寄存器在带有MPU的Cortex-M内核中记录内存保护违规。HFSR硬故障状态寄存器指示硬故障的原因最常见的是FORCED位表示其他故障如BusFault被升级为了HardFault。BFAR总线故障地址寄存器当发生精确总线故障时这个寄存器会保存导致故障的访问地址。这是定位野指针或数组越界的利器。MMFAR内存管理故障地址寄存器记录MPU违规的地址。5.2 故障升级与死锁故障升级是理解HardFault来源的关键。在以下情况一个可配置优先级的故障会“升级”为HardFault对应的故障处理程序被禁用例如你在代码中禁用了UsageFault_Handler。故障处理程序在执行时又触发了同类型或更低优先级的故障例如BusFault_Handler内部代码访问了一个非法地址。任何异常处理程序不限于故障触发了一个优先级不高于自身的故障。死锁如果处理器在执行HardFault_Handler时再次发生了硬故障系统就会进入“死锁”状态。在CC13x2/26x2上这通常会触发一个系统复位。这是最严重的错误意味着你的HardFault处理程序本身可能访问了非法内存或栈已崩溃。5.3 编写健壮的故障处理程序一个基本的HardFault_Handler不应该做复杂的操作因为系统可能已经处于不稳定状态。其核心任务是保存现场立即将关键寄存器如LR, SP保存到全局变量中。获取故障信息读取CFSR、HFSR、BFAR等寄存器。记录或输出将故障信息通过串口打印、保存到非易失性存储器如Flash的特定区域或设置一个软件标志。系统恢复根据严重程度选择软件复位调用NVIC_SystemReset或进入安全模式。// 一个简单的HardFault_Handler示例基于GCC/ARMCC __attribute__((naked)) void HardFault_Handler(void) { __asm volatile( tst lr, #4 \n // 检查EXC_RETURN的位2判断使用的是MSP还是PSP ite eq \n mrseq r0, msp \n // 如果使用MSP将其值存入R0 mrsne r0, psp \n // 如果使用PSP将其值存入R0 ldr r1, [r0, #24] \n // 从栈帧中获取PC故障时的地址 ldr r2, hardfault_handler_c \n // 跳转到C函数R0是栈指针R1是PC bx r2 \n ); } void hardfault_handler_c(uint32_t *stack_pointer, uint32_t fault_pc) { uint32_t cfsr SCB-CFSR; uint32_t hfsr SCB-HFSR; uint32_t bfar SCB-BFAR; uint32_t mmar SCB-MMFAR; // 如果有MPU // 打印或保存这些信息 debug_printf(HardFault at PC: 0x%08lX\n, fault_pc); debug_printf(CFSR: 0x%08lX\n, cfsr); debug_printf(HFSR: 0x%08lX\n, hfsr); if (cfsr (1 15)) { // BFSR的BFARVALID位 debug_printf(BFAR: 0x%08lX\n, bfar); } // 解析CFSR的具体位 if (cfsr (1 25)) { debug_printf( Division by zero\n); } if (cfsr (1 24)) { debug_printf( Unaligned access\n); } if (cfsr (1 18)) { debug_printf( IMPRECISERR Data bus error\n); } if (cfsr (1 17)) { debug_printf( PRECISERR Data bus error\n); } if (cfsr (1 16)) { debug_printf( IBUSERR Instruction bus error\n); } // 死循环或系统复位 while (1) { // 或者调用 NVIC_SystemReset(); } }避坑指南在HardFault_Handler中避免调用任何可能依赖堆栈或静态数据的复杂库函数如printf,sprintf。因为堆栈可能已损坏全局数据区可能已被污染。最安全的方式是使用一个预先初始化好的、使用独立缓冲区的简单串口发送函数或者直接将故障信息写入一个保留的RAM区域供调试器在复位后查看。6. CC13x2/CC26x2事件路由机制剖析在理解了标准的Cortex-M异常模型后我们来看TI在CC13x2/CC26x2这类无线MCU上引入的一个强大特性事件路由Event Fabric。你可以把它理解为一个高度灵活的、硬件级别的“中断路由器”或“事件交换机”。6.1 事件路由是什么为什么需要它传统的中断模型是外设直接连接到NVIC的特定IRQ线。这种方式简单直接但缺乏灵活性。例如一个GPT通用定时器的“比较匹配”事件只能触发它自己固定的中断如果你想用这个事件同时去触发DMA传输就需要在中断服务程序里手动启动DMA这增加了延迟和CPU开销。事件路由机制解耦了事件源谁产生了事件和事件订阅者谁需要响应事件。它像一条内部总线允许几乎任何外设产生的事件信号被路由到多个订阅者包括CPU作为中断这是传统方式。DMA控制器实现外设到内存、内存到外设、内存到内存的自动传输无需CPU干预。例如ADC转换完成事件直接触发DMA将结果搬移到RAM。其他外设实现外设间的直接硬件联动。例如GPT的匹配事件可以直接触发另一个外设如ADC开始采样实现精准的硬件同步。唤醒控制器WUC在低功耗模式下特定事件如GPIO边沿可以直接唤醒MCU而无需先进入中断。技术价值降低CPU负载与功耗将数据搬运、简单响应等任务交给DMA或硬件联动CPU可以更长时间处于睡眠状态。提高实时性与确定性硬件事件触发DMA或另一个外设延迟是纳秒级的且不受其他中断影响。增强设计灵活性通过配置寄存器可以在软件中动态改变事件的连接关系适应不同的应用场景。6.2 架构解析MCU事件总线与AON事件总线CC13x2/26x2有两套事件总线分属不同电源域MCU事件总线位于MCU主电源域连接大部分高速外设如GPT、UART、SPI、DMA、加密加速器等。AON事件总线位于常开Always-On电源域连接低功耗外设如RTC、唤醒控制器WUC、AON GPIO、电池监控器等。即使在MCU主核深度睡眠时AON域仍可工作并响应事件。两个总线通过桥接互联。AON事件总线可以产生事件路由到MCU事件总线作为其输入源从而在MCU睡眠时由AON域的事件将其唤醒。事件类型事件通常是高电平有效的信号。可以是单脉冲也可以是持续电平。对于DMA触发它可能是一个边沿信号对于中断它可能是一个需要软件清零的电平信号。6.3 核心概念事件源、订阅者与选择寄存器事件源产生事件的模块。在MCU事件总线输入事件表如表5-5中每个事件都有一个唯一的编号Event Number和枚举名。例如GPT0A0x10是GPT0定时器A的匹配/捕获中断事件UART0_RX_DMABREQ0x30是UART0接收FIFO达到阈值时产生的DMA突发请求事件。订阅者消费事件的模块。主要订阅者包括CPU事件被路由到NVIC成为CPU可处理的中断。µDMA事件被路由到DMA通道的触发输入启动传输。Radio射频核心的事件。Freeze用于调试冻结系统状态。选择寄存器这是配置灵活性的关键。对于每个订阅者的每个输入通道都有一个对应的选择寄存器。例如DMA通道0的触发源可以选择为GPT0A事件、UART0_RX事件或软件事件等。你通过向这个寄存器写入对应事件源的Event Number就完成了“接线”。配置流程示例用GPT定时器触发ADC采样并通过DMA传输假设我们需要用GPT0的周期匹配事件GPT0A来精确触发ADC采样并将采样结果通过DMA自动存放到数组。配置事件源设置GPT0为定时器模式使能其输出比较A事件GPT0A。这个事件会出现在MCU事件总线上编号为0x10。配置订阅者ADC找到ADC的触发输入选择寄存器例如在CC13x2中ADC可能通过AUX_EVCTL:DMACTL或类似的寄存器来配置触发源。将该寄存器的值设置为GPT0A的事件编号0x10。这样GPT0的匹配事件就会直接触发ADC开始一次转换。配置订阅者DMA为ADC结果配置一个DMA通道。找到该DMA通道的触发源选择寄存器例如UDMA0:CHMAP相关的寄存器将其设置为ADC转换完成事件例如AUX_ADC_DONE, 0x70。这样ADC转换一结束DMA就自动将结果从ADC数据寄存器搬运到目标内存。使能使能GPT0定时器、ADC、DMA通道。整个过程CPU只需要进行初始配置之后的数据采集和搬运完全由硬件事件链自动完成CPU可以处理其他任务或进入低功耗模式。6.4 软件事件SWEV灵活的软件触发事件总线还提供了软件事件SWEV0-SWEV3事件号0x64-0x67。通过写SWEV寄存器对应的位可以在软件中直接“制造”一个事件。这个事件可以像硬件事件一样被路由到任何订阅者。应用场景软件触发DMA当你想手动启动一次DMA传输时可以触发一个连接到DMA通道的软件事件。跨模块同步在软件中设置一个标志同时触发一个事件去通知另一个外设或产生一个CPU中断。测试与调试在不依赖硬件的情况下测试事件路由配置是否正确。7. 实战配置与常见问题排查7.1 基于SDK的事件路由配置步骤以TI Driver为例TI的SimpleLink SDK提供了高级API来简化配置但理解底层寄存器操作依然重要。初始化外设使用GPT_init(),ADC_init()等函数初始化相关外设。配置事件链接这是核心。你需要查阅芯片的技术参考手册和SDK的驱动文档。通常步骤是找到事件源的“事件输出”配置。例如对于GPT需要设置GPTn-TAMR寄存器中的TCACT字段使能比较匹配事件输出。找到订阅者的“触发输入”配置。例如对于ADC调用ADC_setTriggerSource(adcHandle, ADC_TRIGGER_GPT0A)对于DMA调用UDMA_setChannelTrigger(udmaHandle, channel, UDMA_TRIG_ADC_DONE)。在底层这些API会操作对应的事件选择寄存器。使能中断/DMA如果事件最终要触发CPU中断需要配置NVIC优先级并使能IRQ。如果触发DMA需要配置DMA传输控制结构并启用DMA通道。启动启动事件源如启动GPT定时器。7.2 常见问题与排查技巧问题1中断/DMA无法触发。检查清单事件源是否真正产生使用调试器或GPIO翻转来验证你的定时器是否真的到了匹配点ADC转换是否真的完成。确认对应外设的状态寄存器标志位是否被置起。事件路由路径是否连通这是最容易出错的地方。逐级检查事件源的外设是否配置为输出事件例如GPT的TCACT是否配置正确事件选择寄存器的值是否正确写入了目标事件编号查看对应EVTOMCUSEL或DMACHMAP寄存器订阅者是否使能了该事件输入例如ADC的触发使能位DMA通道的触发使能位NVIC/DMA是否使能确认CPU中断已使能且优先级合理或DMA通道已分配并启用。电源和时钟确认相关外设的时钟已开启所在电源域已上电。在低功耗应用中要特别注意外设在睡眠模式下是否仍能产生事件。问题2HardFaultBFAR显示一个奇怪的地址。可能原因DMA或事件触发的访问指向了非法地址。排查检查DMA的源地址和目标地址配置确保在有效的内存范围内SRAM, Flash, 外设寄存器空间。检查外设事件是否在预期的时间产生。一个错误配置的定时器可能产生过快的事件流导致DMA访问越界。如果BFAR地址接近0x20000000SRAM起始但超出芯片SRAM范围可能是栈溢出或堆损坏波及了DMA缓冲区。问题3系统响应变慢或不稳定。可能原因中断或事件过于频繁导致CPU或总线带宽被占满。排查使用分析工具如Segger SystemView或简单的GPIO引脚示波器测量中断服务程序的执行时间和频率。检查DMA传输是否配置为“单次请求”但被误触发为连续的“突发请求”导致总线拥塞。评估事件链的延迟。过于复杂的事件路由A触发BB再触发C可能引入不可预料的累积延迟。问题4低功耗模式下无法被事件唤醒。可能原因AON事件总线配置错误或唤醒源未正确映射。排查确认产生唤醒事件的外设如GPIO, RTC在低功耗模式下仍有供电和时钟位于AON域或配置为低功耗模式保持活动。确认该事件已正确路由到AON事件总线上的唤醒控制器WUC订阅者。检查AON_EVENT:MCUWUSEL或AON_EVENT:AUXWUSEL寄存器。在进入低功耗模式前确保CPU的NVIC中对应的唤醒中断是使能的对于路由到CPU的事件并且系统已配置为允许该事件唤醒如设置PRIMASK等。我个人在实际开发CC26x2低功耗传感器节点时曾遇到一个棘手问题设备在深度睡眠后偶尔无法被GPIO中断唤醒。最终排查发现问题根源是事件路由配置的时机不对。我在外设初始化时配置了GPIO到WUC的事件路由但在每次唤醒后重新初始化外设时没有重新配置AON事件总线的选择寄存器。而AON域在睡眠时是保持状态的但MCU域复位或重新初始化后对AON事件总线的配置映射可能会丢失。解决方案是将AON事件路由的配置代码从外设初始化函数移动到系统唤醒后的初始化流程中确保每次MCU核心激活后唤醒路径都是畅通的。这个坑让我深刻体会到在混合电源域的系统里必须清晰地知道每项配置属于哪个域以及该域在状态转换时的行为。
