1. 从零开始理解CC35xx的中断与事件管理如果你正在基于德州仪器TI的CC35xx系列无线MCU开发物联网或消费电子设备那么“中断”和“事件”这两个词绝对是你绕不开的核心。它们就像是系统的神经系统负责感知外部世界的刺激比如按键按下、数据接收完成、定时器超时并触发快速反应。但CC35xx的中断系统尤其是其集成的“事件管理器”Event Manager远比传统MCU的中断控制器要复杂和强大。它不仅仅是一个简单的信号传递者更是一个高度可配置的“交通枢纽”能够将数十个不同来源的事件灵活地路由到不同的处理单元同时还要兼顾安全状态Secure/Non-secure的隔离。理解这套机制是写出稳定、高效且安全可靠的嵌入式固件的基石。为什么这如此重要想象一下你的设备正在通过Wi-Fi传输关键数据同时需要实时响应蓝牙连接请求并且一个后台的传感器还在定时采样。如果没有一个精心设计的中断和事件管理系统高优先级的任务可能会被低优先级任务阻塞导致数据丢失或响应延迟更糟糕的是一个错误的内存访问可能会让整个系统陷入死锁Lockup而无法恢复。CC35xx基于ARM Cortex-M33内核提供了一套完整的故障处理架构MemManage, BusFault, UsageFault, SecureFault来捕获非法操作并通过“事件管理器”来实现高效、灵活的外设间协同与唤醒。本文将带你深入这套机制的内部不仅告诉你寄存器怎么配置更会解释其背后的设计逻辑、实际调试中如何排查问题以及如何利用这些特性构建更鲁棒的应用。2. 故障处理机制系统稳定性的最后防线在嵌入式系统中并非所有中断都是“好”的。有些中断是由于程序错误如访问非法内存地址、执行未定义指令或硬件异常如总线错误而触发的这类异常情况被统称为“故障”Fault。CC35xx的Cortex-M33内核定义了几类主要的故障每一类都配有专门的状态寄存器Fault Status Register, FSR来精确定位问题根源。正确处理这些故障是防止系统“跑飞”或死机的关键。2.1 四大故障类型详解与状态寄存器解析故障处理程序Fault Handler是内核预定义的中断服务程序。当故障发生时处理器会自动跳转到对应的处理程序。CC35xx主要涉及以下四类可配置优先级的故障以及一个最高优先级的HardFault。1. 内存管理故障MemManage Fault这类故障与内存保护单元MPU或默认内存映射有关通常意味着软件试图访问其无权访问的内存区域。IACCVIOL取指访问违规。例如尝试从标记为“不可执行”的内存区域如数据区取指令。DACCVIOL数据访问违规。例如向只读内存区域写入数据或从完全禁止访问的区域读取数据。MSTKERR在异常压栈保存上下文到堆栈时发生内存管理故障。这通常意味着堆栈指针SP指向了一个无效或受保护的内存区域。MUNSKERR在异常出栈从堆栈恢复上下文时发生内存管理故障。MLSPERR在惰性浮点状态保存时发生故障如果使用了浮点单元。这些状态位记录在MemManage Fault Status Register (MMFSR)中。在调试时首先查看MMFSR的哪个位被置起就能快速定位是哪种类型的内存访问触发了故障。2. 总线故障BusFault总线故障发生在处理器与内存或外设通信过程中例如访问一个不存在的物理地址或设备未就绪。STKERR/UNSTKERR在异常压栈/出栈时发生总线错误。这通常指向堆栈内存区域的总线访问问题可能是堆栈溢出后破坏了相邻区域。IBUSERR指令预取总线错误。处理器在预取指令时遇到了总线错误。LSPERR惰性浮点状态保存时的总线错误。PRECISERR精确数据总线错误。这是最有用的一种当此位置位时故障地址寄存器BFAR中会保存导致故障的确切内存地址。这对于调试非法指针访问至关重要。IMPRECISERR不精确数据总线错误。故障地址可能无法精确定位通常与写缓冲或缓存操作有关调试起来更困难。这些状态位记录在BusFault Status Register (BFSR)中。PRECISERR位和与之关联的BFAR寄存器是解决内存访问崩溃问题的利器。3. 用法故障UsageFault用法故障通常由非法指令或非法的程序状态引起。UNDEFINSTR执行了未定义的指令。可能是程序计数器PC跑飞到了数据区或者尝试执行Thumb不支持的指令。INVSTATE尝试进入无效的指令集状态。例如在Thumb状态下试图执行ARM指令Cortex-M只支持Thumb。INVPC从异常返回时EXC_RETURN值无效。UNALIGNED尝试非对齐的内存访问在某些配置下会被触发。DIVBYZERO除零错误需在CCR寄存器中使能。NOCP尝试访问不存在的协处理器如未使能FPU时使用浮点指令。这些状态位记录在UsageFault Status Register (UFSR)中。它常常能揭示出程序逻辑错误或编译器/链接器配置问题。4. 安全故障SecureFault这是Cortex-M33为TrustZone安全扩展引入的故障类型用于处理安全状态切换中的违规行为。INVTRAN无效的安全状态转换。AUVIOL属性单元违规。INVER无效的异常返回。INVIS/INVEP无效的完整性签名。LSERR/LSPERR惰性状态相关错误。状态位记录在SecureFault Status Register (SFSR)中。在开发涉及TrustZone的安全应用时此寄存器是调试安全边界违规的主要依据。实操心得故障状态寄存器的读取与清除在默认情况下除HardFault外其他故障处理程序可能被禁用。为了进行调试你需要在系统初始化时使能它们通过设置SCB-SHCSR寄存器的对应位。当进入故障处理程序后第一件事就是读取SCB-CFSR组合故障状态寄存器包含了MMFSR、BFSR和UFSR和SCB-SFSR。这些寄存器是“粘性”的一旦置位只有通过向该位写入1才能清除注意有些寄存器是写1清除有些是写0清除务必查阅手册。一个良好的调试习惯是在故障处理程序中将这些寄存器的值、故障地址如SCB-BFAR、程序计数器SCB-PC、链接寄存器SCB-LR的值通过日志或调试器输出。LR在进入异常时的值EXC_RETURN尤其重要它能告诉你异常发生前处理器处于何种模式线程模式/Handler模式和安全状态。2.2 故障升级Escalation到HardFault的深层逻辑HardFault是优先级最高-1的异常它不可屏蔽也无法被禁用。当某些严重情况发生时可配置优先级的故障MemManage, BusFault, UsageFault, SecureFault会被“升级”Escalation为HardFault。理解升级条件对于分析复杂的嵌套异常场景至关重要。升级发生的核心条件是新发生的故障无法得到及时服务。具体来说自递归故障一个故障处理程序在执行时又触发了同类型的故障。例如在BusFault处理函数中又一次发生了总线错误。因为一个处理程序不能抢占自己所以必须升级到HardFault。低优先级嵌套故障一个故障处理程序在执行时触发了另一个优先级相同或更低的故障。例如正在执行的UsageFault处理程序优先级设为5触发了一个BusFault优先级设为5或6。由于新故障的处理程序不能抢占当前正在运行的处理程序因此BusFault被升级为HardFault。未使能的故障一个故障发生了但该类型故障的处理程序未被使能在SCB-SHCSR中禁用。此时该故障会直接升级为HardFault。一个需要特别注意的例外情况文档中特别指出如果在进入BusFault处理程序的堆栈压栈过程中发生了BusFault该BusFault不会升级为HardFault。这听起来有点绕但其设计意图很关键它确保了即使是因为堆栈本身损坏例如栈溢出而导致的故障故障处理程序仍然有机会被执行。虽然此时堆栈内容可能已经混乱但处理程序至少能尝试记录一些信息或进行最基础的恢复操作而不是直接陷入无法处理的死循环。这为诊断最棘手的“栈被踩”问题留下了一线生机。2.3 安全状态下的故障处理与优先级配置CC35xx支持TrustZone安全扩展因此故障和异常也有了安全Secure和非安全Non-secure的属性。这由系统控制块SCB中的AIRCR.BFHFNMINS位控制。当BFHFNMINS 0BusFault、HardFault和NMI被指定为安全异常。此时非安全状态的FAULTMASK_NS寄存器只能屏蔽可编程优先级的异常其作用等同于PRIMASK_NS。当BFHFNMINS 1BusFault、HardFault和NMI被指定为非安全异常。此时系统会引入一个优先级为-3的安全HardFault用于处理针对安全状态的故障。非安全状态的FAULTMASK_NS会将执行优先级提升至-1以屏蔽包括非安全HardFault在内的所有异常而安全状态的FAULTMASK_S则将执行优先级提升至-3以屏蔽包括安全HardFault在内的所有异常。这种设计实现了安全世界和非安全世界之间的异常隔离。安全世界的代码可以处理所有故障而非安全世界的故障处理则受到限制无法干扰安全世界的执行。在配置混合安全属性的项目时必须仔细规划异常的优先级和归属否则可能导致安全漏洞或系统不稳定。2.4 故障地址寄存器FAR的捕获机制与锁死状态对于BusFault、MemManage Fault和SecureFault除了状态寄存器还有对应的故障地址寄存器FAR如MMFAR、BFAR、SFAR。它们用于保存触发故障的访问地址是定位非法指针的“罪证”。这里有一个精妙的硬件机制CC35xx有两个物理的故障地址寄存器一个用于安全世界的故障一个用于非安全世界的故障。关键在于每个物理寄存器一次只能报告一个故障地址。当某个故障发生时如果其对应的*FARVALID位在CFSR或SFSR中被置位并且此时FAR寄存器是“空”的即*FARVALID位为0那么故障地址就会被捕获到FAR中同时*FARVALID位被置1。如果*FARVALID位已经为1表示上一个故障地址还未被读取此时又发生了一个新的、需要报告地址的同类故障那么新的故障地址将不会被记录这个设计是为了保证第一个故障地址不被覆盖因为通常第一个故障才是根本原因。因此在故障处理程序中在读取了FAR值之后必须手动清除对应的*FARVALID状态位才能为捕获下一次故障地址做好准备。锁死Lockup是系统最严重的状态。当发生一个故障且该故障既无法被服务例如其处理程序本身又立即触发故障也无法被升级时例如在HardFault处理程序中又发生了故障处理器就会进入锁死状态。此时处理器停止执行任何指令只有以下三种情况能使其退出系统复位。被更高优先级的异常抢占在锁死状态下这几乎不可能因为HardFault已是最高。被调试器挂起halt。锁死意味着系统已完全失控通常只能通过看门狗或外部复位来恢复。避免锁死的根本方法是确保故障处理程序本身极其简单、健壮并且避免在故障处理中进行复杂的、可能出错的操作如动态内存分配、访问可能故障的外设。3. 事件管理器Event ManagerCC35xx的灵活事件路由中枢如果说故障处理是系统的“免疫系统”那么事件管理器就是系统的“神经系统”。CC35xx的事件管理器是一个高度可配置的组合逻辑路由器它在事件发布者Publishers如外设、GPIO、系统资源和订阅者Subscribers如主机MCU的NVIC、Always-On域、其他外设之间建立连接。它的存在极大地增强了外设间协同工作的灵活性和效率。3.1 核心架构与三种事件类型事件管理器分为AONAlways-On和AAONActive Always-On两个电源域。AON域中的寄存器值在设备进入低功耗模式时得以保持而AAON域中的寄存器则会复位。这直接影响事件唤醒功能的配置。事件路由有三种基本模式直接事件Direct Events发布者的信号直接连接到订阅者无需任何配置。这是一种固定的、硬连线的路径通常用于最常用、延迟要求最严格的中断信号。集中事件Concentrated Events将多个发布者的事件信号“集中”成一个单一的事件信号再发送给订阅者。例如多个GPIO引脚的中断可以集中为一个GPIO组中断送到NVIC。订阅者收到这个集中事件后需要查询具体的状态寄存器来区分是哪个引脚触发的。这种方式节省了NVIC的中断线资源。硬件事件HW Events发布者的信号作为触发事件直接驱动其他外设的硬件操作不经过CPU干预。这是实现高效外设间协作Peripheral-to-Peripheral, P2P的关键。例如ADC可以在定时器事件触发下自动开始一次转换转换完成后又通过DMA事件将数据搬走整个过程无需CPU参与。3.2 中断列表与电源域归属分析根据文档中的中断列表我们可以清晰地看到CC35xx丰富的外设中断资源及其设计考量AAON域外设UART、I2C、SPI、GPTimer部分、ADC、SDIO等大多数通信和定时外设都属于AAON域。这意味着当芯片进入深度睡眠仅AON域保持供电时这些外设及其中断逻辑会掉电。如果希望用这些外设的事件来唤醒系统需要确保事件能路由到AON域的订阅者如ELP。AON域外设与资源RTC、部分GPIO中断、部分定时器事件、以及来自Wi-Fi/BLE核心的错误信号等属于AON域。它们可以在深度睡眠下保持工作是低功耗唤醒的关键来源。订阅者多样性NVIC绝大多数中断的最终目的地触发CPU中断服务程序。ELP事件管理器自身用于低功耗唤醒管理。例如HOST_WLAN_IRQ和HOST_BLE_IRQ既可以到NVIC处理也可以路由到ELP用于唤醒睡眠中的主机MCU。HW表示该事件可以作为硬件事件直接触发其他外设如ADC、Timer的硬件操作。一个关键设计细节GPIO和DMA的中断是集中事件。这意味着所有GPIO引脚的中断会先集中成少数几个如安全和非安全中断信号再提交给NVIC。在ISR中你需要查询GPIO的具体状态寄存器来确定是哪个引脚触发了中断。DMA亦然多个DMA通道的完成或错误中断被集中处理。3.3 低功耗唤醒源配置实战事件管理器在低功耗设计中扮演着核心角色。AON事件管理器中的事件可以被编程并通过“或”逻辑组合成一个单一的唤醒事件连接到电源复位时钟管理PRCM模块。具体配置寄存器是HOSTMCU_AON.CFGWICSNS。配置步骤与思路确定唤醒源你希望用哪个事件来唤醒MCU例如可以是RTC定时器事件RTC_IRQ、某个GPIO的电平变化GPIOx_IRQ、或者来自无线协处理器的信号HOST_WLAN_IRQ。查询事件索引在中断列表中找到对应事件的IRQ Index。例如RTC_IRQ的索引是49。配置CFGWICSNS寄存器将该事件对应的比特位置1。你可以将多个事件的比特位都置1这样任何一个事件发生都会产生唤醒信号。默认情况下该寄存器为0即没有选择任何唤醒发布者这是为了防止意外唤醒。使能低功耗模式在PRCM模块中配置MCU域进入特定的低功耗模式如Sleep, Deep-Sleep。事件触发与清理当配置的唤醒事件发生时PRCM会唤醒MCU域。在MCU唤醒后的初始化代码中需要查询并清除事件管理器中和外设中的中断标志位否则系统可能会立即再次进入睡眠或产生误判。避坑指南唤醒后的状态恢复从深度睡眠唤醒后AAON域的外设是经历了一次复位的。这意味着你之前对UART、SPI等外设的配置波特率、模式等全部丢失了必须在唤醒后的初始化流程中重新配置这些外设。而AON域的外设如RTC、配置好的GPIO中断则保持状态。因此你的系统初始化代码可能需要分为两部分上电初始化和唤醒后初始化。同时注意检查CFGWICSNS等AON域寄存器的配置是否在睡眠中保持通常它们是保持的但最好在唤醒后确认一下。3.4 外设硬件事件选择器实战配置这是事件管理器最强大的功能之一允许你将几乎任何内部事件作为另一个外设的硬件触发源。我们以ADC的硬件触发为例详细解析配置流程。目标配置GPTimer0的某个匹配事件例如GPTIMER0_ADC_Trigger作为ADC转换的硬件启动信号。配置步骤查找映射表查阅文档中的“ADC HW Event Selector Table”。我们需要找到GPTIMER0_ADC_Trigger这个事件对应的“Select Config”值。从表中可知该事件对应的Select Config 2。定位配置寄存器ADC的硬件事件选择由SOC_AON.SPEVTCTL寄存器的[5:0]位域即低6位控制。这个位域被称为ADC字段。计算并写入值我们需要向SOC_AON.SPEVTCTL寄存器的ADC字段写入值2。假设寄存器地址为0x4009_5000此地址需查阅具体器件手册。操作如下以C语言伪代码为例// 首先读取当前寄存器值避免影响其他位 uint32_t reg_val HWREG(SOC_AON_SPEVTCTL); // 清除ADC选择字段的旧值低6位 reg_val ~(0x3F); // 设置新的选择值GPTIMER0_ADC_Trigger (值为2) reg_val | (2); // 写回寄存器 HWREG(SOC_AON_SPEVTCTL) reg_val;配置ADC外设仅仅配置事件管理器还不够你还需要在ADC模块本身将其触发源配置为“外部硬件触发”模式而不是软件触发或连续转换模式。配置GPTimer配置GPTimer0使其在匹配比较时产生相应的ADC_Trigger事件信号。这通常在GPTimer的比较匹配输出控制寄存器中设置。同理对于I2S、PDM、SysTimer、RTC以及GPTimer自身的硬件事件选择流程完全一致在对应的选择表如I2S HW Event Selector Table,PDM HW Event Selector Table等中找到你想要的源事件及其Select Config值。找到对应的配置寄存器SOC_AON.SPEVTCTL用于ADC/I2S/PDMSOC_AON.TMEVTCTL用于SysTimer/RTCSOC_AON.GPT0EVTCTL0等用于GPTimer和正确的位域。使用“读-改-写”操作将Select Config值写入指定位域。灵活应用场景举例音频同步将I2S的DMA请求事件连接到GPTimer的捕获事件从而精确测量音频流的时序。周期性采样用SysTimer的周期性事件触发ADC转换实现无需CPU干预的固定频率数据采集。联动控制用一个GPIO的上升沿作为硬件事件同时触发GPTimer开始计时和ADC开始采样实现事件驱动的同步测量。4. 系统级错误状态寄存器解析与应用除了内核的故障寄存器CC35xx还在SOC互连层级提供了错误状态寄存器如ERRSTS1,ERRSTS2用于捕获片上总线如OCP协议上的错误例如访问不存在的从设备或访问超时。这些寄存器对于诊断复杂的系统集成问题非常有帮助。4.1 ERRSTS1/ERRSTS2片上总线错误侦探ERRSTS1和ERRSTS2寄存器位于SOC_IC系统互连的地址空间。它们是“粘性”寄存器会锁定第一次发生的错误信息直到被显式清除。ERRSTS1 (Offset 0x14)主要捕获发生错误的存储器地址。当OCP从设备响应一个系统错误SERROR时出错的地址会被记录在该寄存器的MADDR字段。这对于定位一个非法访问具体指向哪里至关重要。向该寄存器写入任何值都会清除所有状态位通常写入0。ERRSTS2 (Offset 0x18)提供了更丰富的错误上下文信息位于ERRSTA2字段bits [9:0]Bits [9:6] - Error Cause指示错误来源的控制器或模块如0: Controllers, 1: AON, 2: HSM等。Bits [5:4] - Command Type指示是读操作2还是写操作1导致的错误。Bits [3:0] - Controller ID指示发起错误访问的主控制器ID如0: M33非安全态, 1: M33安全态, 6: 核心等。调试工作流当系统出现难以解释的崩溃或挂起时在HardFault处理程序或看门狗复位前的最后日志中尝试读取ERRSTS1和ERRSTS2。从ERRSTS1获取故障地址。结合你的内存映射表链接脚本判断这个地址是否属于一个有效的外设或内存区域。如果不是很可能是一个野指针。从ERRSTS2解析错误原因和发起者。如果发起者是“M33非安全态”那么问题很可能出在你的应用代码非安全世界。如果发起者是“DMA”那么可能是DMA配置错误传输到了非法地址。在记录错误信息后写入0清除这些寄存器以便捕获下一次错误。4.2 AWSTAT1/AWSTAT2地址监视点状态AWSTAT1和AWSTAT2寄存器用于地址监视点功能这更像是一个高级调试功能。你可以配置硬件监视点当CPU或DMA访问特定的内存地址范围时触发一个事件或设置状态位。这两个寄存器则报告了监视点被命中时的详细信息。AWSTAT1记录被命中的内存地址AWADDR。AWSTAT2记录命中的访问属性。AWCMD字段的Bit 4指示是读还是写Bits [3:0]指示是哪个主设备Master ID发起的访问。这个功能在调试数据竞争Data Race、查找特定变量被意外修改的地方或者跟踪某个缓冲区何时被访问时非常有用。它需要硬件调试单元的支持并且通常需要配合调试器来配置监视点。5. 开发与调试实战从理论到问题解决理解了所有机制后最终要落地到开发和调试中。以下是一些结合了CC35xx特性的实战经验和常见问题排查思路。5.1 中断服务程序ISR编写最佳实践快进快出ISR应尽可能短小精悍。只做最紧急的处理如清除标志位、读取数据到缓冲区、发送信号量或事件标志。繁重的计算应交给任务线程。避免阻塞调用绝对不要在ISR中使用malloc、printf除非是中断安全的版本、或任何可能引起等待的函数如某些RTOS的vTaskDelay。妥善处理重入如果中断频率很高或者ISR中操作了共享资源全局变量、硬件外设要考虑临界区保护。对于CC35xx可以使用__disable_irq()和__enable_irq()或者使用原子操作。明确安全属性如果你的项目使用了TrustZone需要明确每个ISR是运行在安全状态还是非安全状态。非安全世界的ISR不能直接调用安全世界的函数必须通过特定的安全网关SG指令。编译器需要正确的属性标注如__attribute__((cmse_nonsecure_entry))。针对集中事件对于GPIO、DMA这类集中事件的中断在ISR入口处必须读取并判断具体的外设状态寄存器如GPIO的中断状态寄存器GPIO.IRQSTATnDMA的通道状态寄存器来确定是哪个子事件触发了中断并进行相应的处理最后清除具体外设的标志位和NVIC中的中断挂起位。5.2 常见故障场景与排查速查表故障现象可能原因排查步骤与工具系统频繁进入HardFault1. 栈溢出2. 野指针访问3. 数组越界4. 中断优先级配置错误导致嵌套故障升级1. 检查SCB-CFSR和SCB-BFAR/SCB-MMFAR。2. 分析SCB-PC和SCB-LR在反汇编或map文件中定位崩溃位置。3. 使用调试器查看堆栈指针SP是否在预期的栈空间内。4. 检查链接脚本确保栈空间足够。某个外设中断无法触发1. NVIC中该中断未使能2. 外设自身的中断使能位未开启3. 中断服务函数向量表地址错误或函数名不匹配4. 中断被更高优先级中断长时间阻塞1. 确认NVIC_EnableIRQ()已调用。2. 确认外设的IER中断使能寄存器已配置。3. 检查启动文件或向量表定义。4. 检查中断优先级确保该中断未被FAULTMASK或BASEPRI屏蔽。低功耗模式下无法唤醒1. 唤醒源未正确配置到HOSTMCU_AON.CFGWICSNS2. 唤醒源事件本身未产生3. PRCM的低功耗模式配置错误4. AON域外设在睡眠前未正确配置1. 确认CFGWICSNS寄存器值。2. 在睡眠前用调试器或IO输出确认唤醒事件能正常触发中断。3. 检查PRCM的睡眠深度配置。4. 确认用于唤醒的GPIO/RTC等AON外设已在睡眠前配置好并确保其时钟在睡眠下有效。硬件事件触发不工作1. 事件管理器路由寄存器如SPEVTCTL配置错误2. 源外设未正确产生事件信号3. 目标外设未配置为硬件触发模式4. 电源域不匹配AAON域事件无法在深度睡眠下触发AON域外设1. 仔细核对Select Config值和寄存器位域。2. 确认源外设如Timer已使能并配置了事件输出。3. 确认目标外设如ADC的触发源选择寄存器设置为对应的硬件触发输入。4. 考虑电源状态如果系统要进入深度睡眠确保触发链路涉及的所有模块都在AON域或者唤醒流程能正确处理。系统运行一段时间后出现数据错误1. 内存访问越界缓慢破坏堆或静态数据区2. DMA传输配置错误覆盖了关键数据3. 中断重入导致的数据竞争1. 使用ERRSTS1检查是否有总线错误地址。2. 启用MPU保护关键内存区域如栈、静态数据区。3. 检查DMA的源/目标地址和传输长度。4. 对共享资源增加互斥保护关中断、信号量等。5.3 利用调试器进行深入分析现代IDE如Code Composer Studio, IAR Embedded Workbench和调试探针如XDS110提供了强大的实时调试能力。实时变量与寄存器监视在调试时可以实时查看SCB-CFSR、SCB-HFSR等核心寄存器的值以及事件管理器相关寄存器的值观察中断标志位的变化。异常断点可以设置当发生特定异常如HardFault, MemManage时自动断下第一时间捕获现场。性能分析有些工具可以统计中断触发频率和执行时间帮助你发现中断过于频繁或ISR耗时过长的问题。电源域调试在调试低功耗应用时监视AON/AAON域相关寄存器的状态以及PRCM的功耗状态机对于验证唤醒流程是否正确至关重要。CC35xx的中断与事件管理系统是一个层次分明、功能强大的架构。从底层的故障处理保障系统坚固性到灵活的事件路由器提升系统效率和灵活性再到安全状态的隔离为应用保驾护航每一层都需要开发者仔细理解和恰当运用。
