AM62L低功耗管理实战：WKUP_CTRL寄存器配置与深度睡眠调试指南-平芜编程栈

1. 项目概述：AM62L低功耗管理的核心枢纽

在电池供电的嵌入式设备开发中，我们常常面临一个核心矛盾：设备需要时刻准备响应外部事件，但又不能一直“火力全开”地消耗电量。这就好比一个24小时待命的保安，他不可能一直睁大眼睛巡逻，更合理的做法是让他大部分时间在打盹休息，但耳朵依然竖着，一有风吹草动（比如门铃响、传感器触发）就能立刻醒来处理。TI的AM62L Sitara™处理器中的唤醒控制器（Wake-up Controller, WKUP_CTRL）及其对应的内存映射寄存器（Memory-Mapped Registers, MMR），就是实现这种“智能打盹”机制的核心硬件模块。

对于从事AM62L平台开发的嵌入式软件或驱动工程师而言，仅仅知道调用WFI（Wait For Interrupt）指令让CPU进入低功耗状态是远远不够的。真正的挑战在于，如何确保系统能安全、可控地进入深度睡眠（Deep Sleep），又如何能通过预设的“闹钟”（如RTC定时器、GPIO电平变化）或“敲门声”（如UART数据、CAN报文）可靠地唤醒。这一切的精细控制，都依赖于对WKUP_CTRL_MMR寄存器组的透彻理解和正确配置。

本文将从一线开发者的实战视角出发，抛开手册中冰冷的寄存器列表，深入解读AM62L处理器中与低功耗管理最相关的几个关键WKUP_CTRL_MMR寄存器。我会结合自己的调试经验，不仅告诉你每个比特位是干什么的，更会解释在什么场景下需要配置它、配置时要注意哪些“坑”，以及如何通过读取状态寄存器来诊断低功耗流程是否按预期执行。无论你是在设计一个由纽扣电池供电的传感器节点，还是一个需要超长待机的智能门锁，掌握这些寄存器的玩法，都将是你优化系统功耗、提升产品竞争力的关键一步。

2. 核心寄存器功能解析与设计思路

AM62L的WKUP_CTRL模块是一个独立于主应用处理器（Cortex-A核）的电源管理单元，它即使在主域（MAIN Domain）断电的深度睡眠状态下也能保持供电和运行。其MMR寄存器就像是这个“守夜人”的指挥面板，我们通过配置它们来设定守夜规则。理解这些寄存器的设计逻辑，比死记硬背地址偏移量更重要。

2.1 权限与状态监控寄存器：系统的“门卫”与“仪表盘”

在允许系统进入深度睡眠之前，必须确认没有“不合规”的操作在进行。WKUP_CTRL_MMR_CFG5_PM_PERMISSION寄存器就是这个“门卫”。它是一个只读寄存器，实时反映哪些因素正在阻止或延迟深度睡眠的进入。

Bit 1: PM_PERMISSION_SECURITY_ACTIVE：当安全监控子系统（SMS）处于活动状态时，此位为1。SMS可能在进行安全相关的操作（如加解密、密钥管理），此时系统必须保持清醒。在调试低功耗无法进入的问题时，首先应该检查此位。如果它为1，就需要检查SMS相关的任务或驱动是否已妥善挂起。
Bit 0: PM_PERMISSION_DEBUG_ACTIVE：当调试器（如JTAG/SWD）处于连接和活动状态时，此位为1。这非常关键！在开发阶段，如果调试器连着，系统是绝对无法进入深度睡眠的。很多新手会在这里卡住，明明代码流程对了，但功耗就是下不去。务必在测量深度睡眠功耗时，断开调试器，或者通过软件命令使调试接口进入非侵入式模式。

如果说PM_PERMISSION是门卫，那么WKUP_CTRL_MMR_CFG5_WFI_STATUS和WKUP_CTRL_MMR_CFG5_SLEEP_STATUS就是系统状态的“仪表盘”。

WFI_STATUS寄存器让你能“窥探”各个CPU核心是否真的执行了WFI指令并进入了等待状态。例如，WFI_STATUS_MPUSS0_CPU0_WFI位反映Cortex-A53 Core 0的状态。在软件流程上，你让核心执行了WFI()，但如何确认硬件真的收到了这个请求？读取这个寄存器就能验证。有时因为某些中断未被正确屏蔽或清理，核心可能无法进入WFI，这个寄存器是重要的调试依据。

SLEEP_STATUS寄存器则记录了深度睡眠进入和退出的“历史事件”。其中两个位尤为重要：

Bit 31: SLEEP_STATUS_EXITED_SLEEP：这是一个“写1清除”的位。如果系统成功进入了深度睡眠（HFOSC时钟被关闭），然后在唤醒后，此位会被置1。你可以通过检查此位来确认上一次低功耗周期是否真的发生了时钟门控。如果流程走了但此位没置1，说明可能在进入深度睡眠的最后一刻被某个 pending 的中断打断了。
Bit 28: SLEEP_STATUS_MAIN_DS：同样“写1清除”。它捕获了主域（MAIN Domain）因深度睡眠退出而引发的上电复位事件。这有什么用？它帮助软件区分：本次启动是一次冷启动（Cold Reset），还是一次从深度睡眠中被唤醒的热启动（Warm Reset）。对于需要恢复上下文的应用程序，这个信息至关重要。

2.2 深度睡眠控制寄存器：下达具体指令

当“门卫”放行，“仪表盘”显示各核心就绪后，就需要通过控制寄存器下达具体指令。WKUP_CTRL_MMR_CFG5_DEEPSLEEP_CTRL寄存器用于强制I/O引脚进入深度睡眠模式。

Bit 8: DEEPSLEEP_CTRL_FORCE_DS_MAIN：写1将强制所有主域I/O进入深度睡眠。这通常意味着I/O的电平会被锁定（保持或置为高阻），泄漏电流降到最低。注意：在操作此位前，必须确保所有主域I/O的外设驱动都已正确配置了睡眠状态（例如，UART TX引脚应设置为输出低或高阻，避免意外电平）。
Bit 0: DEEPSLEEP_CTRL_FORCE_DS_WKUP：写1将强制所有唤醒域I/O进入深度睡眠。这里有个大坑：唤醒域I/O（如某个用作唤醒源的GPIO）如果被强制睡眠，它可能就无法检测到唤醒事件了！所以，这个位的使用必须非常小心。通常，对于配置为唤醒源的GPIO，我们不应该强制其睡眠，而是依靠硬件自动管理。这个寄存器更适用于那些明确知道在睡眠期间完全不需要使用的I/O组。

另一个有趣的寄存器是WKUP_CTRL_MMR_CFG5_DS_MAGIC_WORD。它是一个32位可读写的“魔法字”寄存器。在复杂的低功耗序列中，软件可以在这里写入一个特定的值（例如0xDEADBEEF），作为进入某个特定低功耗状态的“信物”。在唤醒后的初始化代码中，可以读取这个寄存器。如果值匹配，说明系统是从深度睡眠中恢复，需要执行恢复流程（如重新初始化DDR）；如果不匹配，则按冷启动处理。这为软件状态机提供了一个简单的、在深度睡眠中能保持的存储点。

2.3 唤醒源配置寄存器：设置“闹钟”和“触发器”

系统睡着了，靠什么唤醒？WKUP_CTRL_MMR_CFG5_WKUP0_EN和WKUP_CTRL_MMR_CFG5_WKUP0_SRC这对寄存器就是用来管理和监控唤醒源的。

WKUP0_EN是使能寄存器，像是一个开关面板。你可以按需打开特定唤醒源的使能位：

Bit 7: EN7 (WKUP_RTC0)：使能RTC定时器唤醒。这是最常见的定时唤醒方式。
Bit 2: EN2 (WKUP_GPIO0)：使能某个唤醒域GPIO的电平/边沿变化作为唤醒源。
Bit 1: EN1 (WKUP_USART0), Bit 0: EN0 (WKUP_I2C0)：使能串行通信接口在收到数据时的唤醒（通常需要接口在睡眠时保持部分功能供电，即“唤醒on RX”功能）。
Bit 18: EN18 (RTC IO Wakeup Event)和Bit 16: EN16 (MAIN_IO_DAISY_CHAIN)：涉及更复杂的I/O菊花链唤醒逻辑，用于检测主域I/O上的特定事件。

WKUP0_SRC是状态寄存器，它是一个“事件记录本”。当某个使能的唤醒事件实际发生时，对应的状态位会被硬件置1。重要提示：这个寄存器的位大多是“写1清除”（R/W1TC）。这意味着在唤醒中断服务程序（ISR）中，为了识别是哪个源唤醒了系统，你需要读取这个寄存器，并在处理完事件后，向相应的位写1来清除该状态标志。如果不清除，该唤醒事件可能会被误判为持续发生。

2.4 看门狗与时钟控制：睡眠时的“安全措施”

系统深度睡眠时，主域的看门狗（Watchdog）通常需要被暂停，否则它会因为主时钟停止而超时，导致系统被错误复位。WKUP_CTRL_MMR_CFG5_WWDx_CTRL寄存器（x为0或1）就是用于此目的。

Bit[3:0]: WWDx_CTRL_WWD_STOP：这个4位字段必须被精确地写入0xA（二进制1010）才能挂起对应的看门狗/RTI模块。写入任何其他值都等同于0x0（即看门狗继续运行）。这里的操作必须原子化，通常是一条32位写指令直接写入0xA到该字段对应的位置。分次读写可能导致误操作。

时钟是功耗的大头。WKUP_CTRL_MMR_CFG5_PMCTRL_MOSC_STARTUP寄存器用于控制主振荡器（HFOSC）从睡眠中唤醒后的稳定时间。

Bit[19:0]: SETUP_TIME：这个值定义了HFOSC时钟启动后，需要等待多少个时钟周期，才将其输出给SOC（系统级芯片）其他部分。这是因为振荡器从启振到频率稳定需要时间。如果这个时间设置太短，系统可能在时钟不稳定时就开始运行，导致不可预知的行为。TI手册给出的复位值是0xBC00（十进制48128），这是一个比较保守的值。在确保系统稳定的前提下，你可以根据实际使用的振荡器特性，尝试适当减小这个值以缩短唤醒延迟，但这需要严格的测试。

2.5 复位与调试控制寄存器：最后的保障与诊断

低功耗流程也可能出错，WKUP_CTRL_MMR_CFG5_RST_CTRL和RST_SRC寄存器帮助我们进行控制和诊断。

RST_CTRL提供了一些复位控制选项，例如RST_CTRL_SW_WARMRESET字段（Bit[3:0]）允许软件触发一次主域热复位。这在深度睡眠唤醒后，如果发现关键硬件状态异常，可以作为一种恢复手段。写入值0x6会强制复位，写入0xF则无操作。

RST_SRC则是一个“黑匣子”记录器。它记录了上一次热复位或主域上电复位的原因。各位（SRC0-SRC11）对应不同的复位源，例如：

SRC1: 由SW_WARMRESET请求引起的复位。
SRC4/SRC5: 由MPU看门狗0/1超时引起的复位。
SRC11: DDRSS超时复位。当系统从低功耗状态异常复位时，首先就应该读取这个寄存器，看是否是看门狗超时（可能低功耗流程卡死）、DDR错误或是软件触发的复位，这能极大缩小问题排查范围。

3. 低功耗模式配置实战流程

理解了各个寄存器的作用后，我们来看一个典型的、使AM62L进入深度睡眠（Deep Sleep）并依靠RTC定时唤醒的软件配置流程。这个过程需要主域（A核）软件和唤醒域（M核或R5F）软件的协同。

3.1 进入深度睡眠前的准备工作

在主应用处理器（Cortex-A）决定进入低功耗之前，必须完成一系列清理和配置工作，确保睡眠过程平稳、唤醒后可恢复。

第一步：保存上下文与配置外设

// 1. 保存必要的运行上下文（如变量、寄存器状态）到Always-On电源域的内存（如TCM或特定SRAM）。 save_cpu_context(&sleep_context); // 2. 配置所有主域外设进入低功耗状态。 // 例如：关闭GPU、显示接口，将UART、SPI等接口配置为睡眠状态，设置未使用的I/O为安全状态（低功耗）。 configure_peripherals_for_sleep(); // 3. 如果需要保留DDR内容，则配置DDR进入自刷新（Self-Refresh）模式。 // 这通常涉及配置DDR控制器（DDRSS）的相关寄存器。 ddr_enter_self_refresh(); // 4. 清理所有可能阻止睡眠的中断标志。 // 确保没有pending的中断会立即将CPU拉出WFI状态。 clear_all_pending_irqs();

第二步：配置唤醒控制器（WKUP_CTRL MMR）这部分通常由运行在唤醒域（如SMS Cortex-M4F）上的固件负责，或者由A核在进入WFI前直接配置。我们假设A核有权限访问这些MMR。

// 1. 定义WKUP_CTRL_MMR基地址 (来自TRM: 0x43050000) #define WKUP_CTRL_MMR0_BASE 0x43050000 // 2. 使能所需的唤醒源（例如RTC定时器，对应WKUP0_EN寄存器的Bit 7） volatile uint32_t *wkup_en_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x4030); *wkup_en_reg |= (1 << 7); // 使能WKUP_RTC0唤醒源 // 3. 配置RTC定时器产生唤醒事件（此处为伪代码，具体寄存器属于RTC模块） // 例如，设置RTC比较器（ALARM）在10秒后触发。 rtc_set_alarm(10); // 4. （可选但推荐）清除上一次可能残留的唤醒状态标志 volatile uint32_t *wkup_src_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x4040); *wkup_src_reg = 0xFFFFFFFF; // 向所有状态位写1以清除 // 5. 检查是否有因素阻止睡眠（安全、调试等） volatile uint32_t *pm_perm_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0xA0); while ((*pm_perm_reg & 0x3) != 0) { // 如果PM_PERMISSION_SECURITY_ACTIVE或DEBUG_ACTIVE为1，则循环等待或处理 // 例如，确保调试器已断开，或等待SMS安全操作完成。 handle_blocking_conditions(); } // 6. 挂起主域看门狗，防止其在睡眠期间超时复位 volatile uint32_t *wwd0_ctrl_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x1000); *wwd0_ctrl_reg = (0xA << 0); // 写入魔法值0xA到WWD_STOP字段

第三步：执行最后的屏障操作并进入WFI在触发睡眠前，需要确保所有对内存和寄存器的配置操作都已经完成，并且后续的指令流不会被预取或乱序执行打乱。

// 1. 数据内存屏障和数据同步屏障，确保之前的配置写入对后续操作可见。 __DSB(); // Data Synchronization Barrier __ISB(); // Instruction Synchronization Barrier // 2. 可选：将I/O强制进入深度睡眠（确保主域I/O外设已妥善处理） volatile uint32_t *deep_sleep_ctrl_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x160); *deep_sleep_ctrl_reg |= (1 << 8); // 强制MAIN IOs进入深度睡眠 // 注意：对于WKUP IOs (Bit 0)，除非确定不用作唤醒源，否则不要轻易强制睡眠。 // 3. 执行WFI指令，核心进入等待中断状态。 __WFI(); // 执行到此，Cortex-A核心时钟可能已停止，代码暂停。

3.2 唤醒后的恢复流程

当RTC定时器事件触发后，唤醒域逻辑会启动主域的上电序列。主域复位后，程序会从复位向量开始执行（通常是Bootloader）。Bootloader或早期启动代码需要判断复位原因，并决定是跳转到普通应用还是低功耗恢复流程。

第一步：判断唤醒源与系统状态

// 1. 读取RST_SRC寄存器，判断是否为深度睡眠唤醒导致的热复位。 volatile uint32_t *rst_src_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x4010); uint32_t reset_source = *rst_src_reg; // 2. 读取SLEEP_STATUS寄存器，确认深度睡眠退出事件。 volatile uint32_t *sleep_stat_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x410); uint32_t sleep_status = *sleep_stat_reg; // 3. 读取WKUP0_SRC寄存器，明确是哪个唤醒源触发了唤醒。 volatile uint32_t *wkup_src_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x4040); uint32_t wakeup_source = *wkup_src_reg; if ((sleep_status & (1 << 31)) != 0) { // 检查SLEEP_STATUS_EXITED_SLEEP位 // 系统是从深度睡眠中被唤醒的 if ((wakeup_source & (1 << 7)) != 0) { // ���查是否是RTC唤醒 // 处理RTC唤醒事件 handle_rtc_wakeup(); // 清除唤醒状态标志（写1清除） *wkup_src_reg = (1 << 7); } // 清除睡眠状态标志 *sleep_stat_reg = (1 << 31) | (1 << 28); // 写1清除EXITED_SLEEP和MAIN_DS位 }

第二步：恢复系统上下文与外设

// 1. 恢复DDR控制器到正常模式（如果之前进入了自刷新）。 ddr_exit_self_refresh(); // 2. 恢复主域I/O状态（如果之前强制进入了深度睡眠）。 volatile uint32_t *deep_sleep_ctrl_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x160); *deep_sleep_ctrl_reg &= ~(1 << 8); // 取消强制MAIN IOs深度睡眠 // 3. 恢复看门狗运行。 volatile uint32_t *wwd0_ctrl_reg = (uint32_t *)(WKUP_CTRL_MMR0_BASE + 0x1000); *wwd0_ctrl_reg = 0x0; // 写入非0xA值，看门狗恢复计数 // 4. 重新初始化必要的外设（时钟、GPIO、通信接口等）。 reinitialize_critical_peripherals(); // 5. 从Always-On内存中恢复CPU上下文。 restore_cpu_context(&sleep_context); // 6. 跳转回主应用程序或继续执行。 jump_to_main_application();

4. 常见问题排查与调试技巧实录

低功耗调试是嵌入式开发中最令人头疼的环节之一。问题往往表现为“功耗降不下去”、“睡下去醒不来”或“唤醒后系统异常”。下面是我在实际项目中总结的一些排查思路和技巧。

4.1 问题一：系统无法进入深度睡眠，功耗居高不下

现象：软件执行了WFI流程，但测量整板电流发现与运行态相差无几，SLEEP_STATUS_EXITED_SLEEP位始终为0。

排查步骤：

检查PM_PERMISSION寄存器：这是第一步。通过调试器读取WKUP_CTRL_MMR_CFG5_PM_PERMISSION（0x430500A0）。如果Bit 0 (DEBUG_ACTIVE)为1，请确认调试器是否已物理断开或软件禁用了调试端口。如果Bit 1 (SECURITY_ACTIVE)为1，需要检查SMS固件或相关安全驱动是否在后台运行任务。
检查WFI_STATUS寄存器：读取WKUP_CTRL_MMR_CFG5_WFI_STATUS（0x43050400）。确认你期望进入WFI的CPU核心（如MPUSS0_CPU0_WFI）对应的位是否为1。如果为0，说明该核心并未成功进入等待状态。原因可能是：
- 中断未屏蔽/未清理：在进入WFI前，本地中断（如CPU定时器）是否已禁用？全局中断控制器（GIC）中是否有pending的中断未处理？确保在调用__WFI()前，执行了__disable_irq()并清理了中断标志。
- 内存访问未完成：在WFI前，是否有DMA传输正在进行？是否有缓存数据未写回内存？使用__DSB()屏障指令确保所有内存操作完成。
检查时钟和电源域：确认除了唤醒域，其他所有不需要的电源域（如GPU、某些外设域）是否已被正确关闭。参考芯片的电源管理手册，检查相关PD（Power Domain）控制寄存器的状态。
使用示波器探测关键信号：这是硬件层面的验证。可以测量主晶振（HFOSC）的引脚或主域核心电源的使能信号。如果系统成功进入深度睡眠，你应该能看到HFOSC时钟停止，或者核心电源电压被关断（取决于具体的低功耗模式）。

4.2 问题二：系统可以进入睡眠，但无法被预定事件唤醒

现象：系统电流确实降到了深睡眠级别，但RTC定时到了或GPIO触发后，系统毫无反应。

排查步骤：

确认唤醒源配置：
- 使能位：再次读取WKUP0_EN寄存器，确认你打算使用的唤醒源对应位确实被置1。软件配置可能被其他代码段意外修改。
- 唤醒域电源：确保产生唤醒事件的模块（如RTC、GPIO控制器）所在的电源域在睡眠期间是保持供电的（即位于Always-On或Wake-up Domain）。如果它的电源被关闭，自然无法产生唤醒事件。
确认唤醒事件本身：
- RTC Alarm：确认RTC模块的ALARM比较值设置正确，并且RTC中断/事件输出已正确映射到WKUP_CTRL。可以用一个简单的测试程序，不让系统睡眠，只配置RTC Alarm并等待中断，看是否能触发。
- GPIO唤醒：这是最容易出错的地方。首先，确认该GPIO引脚是否被复用为唤醒功能（而非普通GPIO）。其次，检查唤醒触发的条件（边沿上升、下降或电平）是否配置正确。一个常见的坑是：配置为边沿触发，但睡眠期间引脚电平保持不变，没有发生边沿跳变。或者配置为高电平触发，但引脚默认是低电平。用示波器观察该引脚在睡眠期间的实际波形至关重要。
检查唤醒状态寄存器：在系统通过其他方式（如复位）恢复后，立即读取WKUP0_SRC寄存器。看看预期的唤醒源状态位是否被置1。如果置1了，说明唤醒事件确实产生了，并传递到了WKUP_CTRL。问题可能出在唤醒后的上电/复位序列上。如果没置1，说明问题出在唤醒事件生成或传递路径上。
检查复位源：读取RST_SRC寄存器。有时唤醒流程可能触发了看门狗复位（SRC4/SRC5）或其他异常复位，导致系统直接重启而非正常唤醒。这可能是唤醒后的初始化代码太慢，看门狗来不及被恢复所致。

4.3 问题三：唤醒后系统运行异常，数据丢失或外设失灵

现象：系统能被唤醒，但应用程序跑飞、数据错乱，或某些外设无法正常工作。

排查步骤：

区分冷启动与热启动：首先读取SLEEP_STATUS_MAIN_DS位和RST_SRC寄存器。确认系统是从深度睡眠唤醒（热启动），还是发生了完全复位（冷启动）。你的恢复代码路径是否正确？
上下文保存与恢复：这是软件问题的重灾区。检查进入睡眠前保存到Always-On内存的数据，在唤醒后是否完好无损。确保保存和恢复的代码是原子的，且不会在保存过程中被中断打断。对于CPU核心寄存器（如CP15协处理器寄存器），是否需要保存？AM62L的Cortex-A核在深度睡眠下，这些寄存器是丢失的，需要Bootloader或安全固件在唤醒序列中恢复。
外设重新初始化：深度睡眠下，大多数主域外设的寄存器状态都会丢失。唤醒后，必须像系统冷启动一样，重新初始化这些外设（时钟、GPIO复用、控制器模式等）。不能假设外设保持睡眠前的状态。一个检查清单非常有用。
时钟系统状态：唤醒后，系统时钟（PLL、分频器等）是否恢复到了睡眠前的配置？有些芯片在深度睡眠时会关闭PLL，唤醒后需要软件重新使能和等待锁定。检查系统主频是否正确。
DDR内存内容：如果你依赖DDR在睡眠中保持数据（通过自刷新模式），需要确认：
- 进入睡眠前，DDR是否正确进入了自刷新模式？
- 唤醒后，DDR控制器是否在访问DDR之前，先正确退出了自刷新模式并完成了重新初始化？
- DDR的时序参数在唤醒后是否重新加载？有些芯片需要从非易失性存储器中重新配置DDR控制器。

4.4 调试工具与技巧

利用调试域（Debug Domain）： AM62L的调试域在深度睡眠时可能仍部分供电。可以尝试在关键流程（如WFI前、唤醒后第一时间）通过一个在调试域保持供电的GPIO（如果存在）输出脉冲，用逻辑分析仪抓取，以勾勒出软件执行的时间线。
打印日志到非易失性存储器：在低功耗流程的关键节点，将状态信息（如寄存器值）写入一块Always-On的SRAM或RTC备份寄存器。在系统唤醒或复位后，再将这些日志读出来分析。这是一种“飞行记录仪”式的调试方法。
循序渐进：不要一开始就追求最低功耗。先配置最简单的唤醒源（如一个GPIO按钮），让系统能稳定地“睡”和“醒”。然后再��步添加更复杂的元素，如RTC、外设唤醒、DDR保持等。每步都验证功耗和功能。
仔细阅读勘误表（Errata）： TI的芯片通常有发布勘误表。其中很可能记录了低功耗模块的已知硬件问题及规避方法。在遇到无法解释的怪异现象时，查阅勘误表是必须的步骤。