1. 项目概述：为什么嵌入式开发者必须精通电源管理？

如果你正在开发一款依靠电池供电的物联网设备，比如一个需要联网上报数据的温湿度传感器，或者一个智能门锁，那么“续航”这个词绝对是你产品规格书里最扎眼、也最让你头疼的指标之一。客户可能要求设备在单次充电或更换电池后工作数月甚至数年，而你的代码还在以80MHz全速运行，Wi-Fi模块也时刻在线，这显然是个不可能完成的任务。问题的核心，就在于如何让设备在“需要干活的时候火力全开，不需要的时候彻底躺平”。

这正是电源管理和低功耗模式要解决的终极问题。它不是简单的“关掉屏幕”，而是一套精细到时钟周期和电压域的复杂系统工程。今天，我们就以德州仪器（TI）的CC32xx系列Wi-Fi微控制器为例，深入它的“五脏六腑”，看看这颗芯片是如何通过硬件架构和软件API的完美配合，实现从毫安级到微安级的功耗跨越。CC32xx内部集成了一个高度集成的片上电源管理单元（PMU），它就像一个智能的“能源管家”，能根据系统需求动态调整供电策略。而开发者手中的武器，就是一套名为PRCM（Power, Reset, and Clock Management）的驱动API。通过它，我们可以命令CPU进入不同深度的“睡眠”，从浅眠（SLEEP）到深度昏迷（HIBERNATE），每一种模式都对应着不同的唤醒速度和功耗代价。

理解并熟练运用这些模式，意味着你能在代码层面直接干预设备的能耗曲线。例如，让传感器每隔十分钟从深度睡眠中醒来，采集数据并通过Wi-Fi发送，然后迅速再次入睡，整个过程平均电流可能只有几百微安。这对于那些部署在偏远地区、难以更换电池的工业传感器网络而言，是决定项目成败的关键技术。接下来，我将从硬件原理出发，逐步拆解CC32xx的四种核心低功耗模式，并手把手带你用PRCM API实现一个完整的、可落地的低功耗应用框架。

2. CC32xx电源管理硬件架构深度解析

在写第一行低功耗代码之前，我们必须先搞清楚芯片的“身体构造”。CC32xx的电源管理并非软件层面的简单开关，而是由硬件PMU、全局电源复位时钟管理器（GPRCM）和应用处理器时钟管理器（ARCM）共同构成的精密体系。

2.1 片上电源管理单元（PMU）与供电配置

CC32xx的PMU最令人称道的一点是，它允许设备直接连接电池，无需外部复杂的稳压电路。这极大地简化了系统设计，降低了BOM成本和PCB面积。它主要支持两种供电配置：

宽电压电池连接模式（VBAT Wide-Voltage）：这是最常用、最灵活的方案。你只需要将一颗电压在2.1V至3.6V之间的电池（如单节锂离子电池或两节AA电池）直接连接到芯片的VBAT引脚。PMU内部的高效DC-DC转换器会自动将输入电压转换为芯片内部各个模块所需的核心电压（如0.9V-1.2V给数字逻辑，1.8V-1.9V给模拟和射频部分）。这种模式充分利用了电池的整个放电曲线。

预稳压1.85V模式（Pre-Regulated 1.85V）：如果你对电源纹波和瞬态响应有极致要求，或者系统已经存在一个高质量的1.85V电源轨，可以选择此模式。此时，你需要将一个外部稳压器产生的、非常“干净”的1.85V电源直接提供给芯片的特定引脚。PMU内部的ANA1-DCDC和PA-DCDC转换器会被旁路，由外部电源直接供电。这种模式能提供最低的噪声，但增加了外部元件。

注意：芯片会自动检测DC-DC引脚的状态来识别当前处于哪种供电配置，无需软件干预。选择哪种模式取决于你的应用场景：对成本和续航敏感，选宽电压模式；对射频性能或电源纯净度要求极高，选预稳压模式。

PMU内部的关键模块包括为数字核心供电的Dig-DCDC、为模拟/RF供电的ANA1-DCDC、为Wi-Fi功放供电的PA-DCDC，以及一个至关重要的休眠控制器（Hibernate Controller）。这个控制器是超低功耗的基石，它管理着32.768kHz晶体振荡器、RTC计数器、GPIO唤醒监控以及两个由电池直接供电的32位保持寄存器（OCR）。即使在最深的HIBERNATE模式下，数字逻辑全部掉电，这个控制器和RTC依然靠微弱的“生命体征”运行着。

2.2 掉电保护：BROWNOUT与BLACKOUT

在电池供电场景下，电压跌落是常态。CC32xx用两个硬件机制来确保系统在异常掉电时行为可控：

BROWNOUT（欠压）：当供电电压低于某个阈值（宽电压模式为2.1V，预稳压模式为1.74V）时，PMU会判定为BROWNOUT。此时，所有DC-DC转换器关闭，数字逻辑电源被切断以保护电路。但休眠控制器、RTC和那两个OCR寄存器会继续保持运行，因为它们由输入电源直接供电。一旦电压恢复至阈值以上，芯片会执行一次完整的重启。这个机制防止了系统在电压不足时发生不可预知的行为。

BLACKOUT（掉电）：这是更严重的状况，通常意味着电池即将耗尽，电压跌至约1.4V以下。此时，连休眠控制器和RTC都会被强制复位，整个芯片回到一个“干干净净”的初始状态，其效果等同于拉低了芯片的复位引脚（nRESET）。BLACKOUT确保了当电压低到无法维持任何可靠操作时，系统能确定性地复位，避免残留的寄存器状态在下次上电时引发问题。

理解这两个状态对于设计可靠的低功耗产品至关重要。例如，你的软件可以检测到BROWNOUT事件（通过复位原因查询API），然后主动进入HIBERNATE模式，等待电压恢复或用户更换电池，而不是在反复的BROWNOUT重启中耗尽最后一点电量。

2.3 全局与本地时钟管理：GPRCM与ARCM

CC32xx是一个多处理器系统（应用处理器、网络处理器、WLAN MAC/PHY），各子系统可以独立地在活跃和睡眠状态间切换。协调这个“交响乐团”的是全局电源复位时钟管理器（GPRCM）。

GPRCM接收来自各个子系统的睡眠请求和唤醒事件。例如，当你的应用代码调用PRCMLPDSEnter()请求进入低功耗深度睡眠时，这个请求会发给GPRCM。但GPRCM不会立即执行，它要“询问”网络处理器和Wi-Fi子系统：“你们忙完了吗？”如果网络侧还在传输数据，GPRCM会暂时“按住”应用处理器，直到所有子系统都准备好进入低功耗状态，芯片才会整体切换到LPDS模式。这种架构对应用开发者是透明的，你无需关心其他子系统在干什么，只需管理好自己的状态，大大简化了编程模型。

在应用处理器内部，则有一个应用复位时钟管理器（ARCM）。它负责更细粒度的控制，比如为UART、I2C、SPI等具体外设模块提供时钟、进行复位。但请注意，ARCM没有电源控制功能。在CC32xx中，应用处理器是一个统一的电源域，不支持对外设进行单独的电源门控，因为在高性能多处理器系统中，这种细粒度门控带来的功耗收益并不显著。

3. CC32xx四大低功耗模式详解与对比

CC32xx为应用处理器定义了四个层级的低功耗模式，功耗逐级降低，但唤醒延迟和状态丢失程度也逐级增加。选择哪种模式，取决于你的任务对“响应速度”和“续航时间”的权衡。

3.1 ACTIVE（活跃）模式

这是芯片全速工作的状态。Cortex-M4内核运行在80MHz，所有需要的外设在其配置的时钟频率下运行。此时功耗最高，但性能也最强，用于处理传感器数据、运行复杂算法、通过Wi-Fi高速传输数据等。

3.2 SLEEP（睡眠）模式

你可以把它理解为CPU的“小憩”。通过调用PRCMSleepEnter()，内核会执行一条WFI（Wait For Interrupt）指令并停止执行，直到一个中断事件将其唤醒。此时，CPU的时钟被门控（关闭），但系统时钟、PLL、SRAM以及所有外设的时钟和状态都完全保持。

• 功耗：比ACTIVE模式降低约3mA。
• 唤醒延迟：极低，几乎是“瞬间”唤醒（几个时钟周期），因为系统上下文完全保留，程序从PRCMSleepEnter()调用之后的下一条指令继续执行。
• 适用场景：处理短间隔的空闲等待。例如，在等待一个定时器超时或一个GPIO中断的短暂间隙，进入SLEEP模式可以节省可观电量。需要注意的是，默认情况下，外设在SLEEP模式下的时钟是关闭的。如果你的应用需要在SLEEP模式下让某个外设（如UART）继续工作以接收数据，必须提前通过PRCMPeripheralClkEnable(peripheral, PRCM_SLP_MODE_CLK)显式启用其睡眠时钟。

3.3 DEEPSLEEP（深度睡眠）模式

比SLEEP模式更进一步。通过PRCMDeepSleepEnter()进入。在此模式下，不仅CPU时钟被门控，连PLL也被关闭以节省更多功耗。SRAM的内容默认会被保持（也可按64KB列配置），但处理器和外设的寄存器状态会丢失。

• 功耗：比ACTIVE模式降低约5mA。
• 唤醒延迟：高于SLEEP，因为需要重新使能并锁定PLL，通常需要几百微秒。
• 重要限制：TI官方文档明确指出，不建议在CC32xx中将外设与DEEPSLEEP模式结合使用。这是因为进入DEEPSLEEP后，外设的时钟和上下文可能处于不确定状态，唤醒后需要完整的重新初始化，增加了软件复杂性和出错风险。在CC32xx的设计中，DEEPSLEEP更像是一个通向更低功耗模式的过渡状态，或者为其他架构兼容性而保留的模式。对于真正的低功耗应用，我们应重点关注接下来的LPDS和HIBERNATE模式。

3.4 LPDS（低功耗深度睡眠）模式

这是CC32xx实现“常连接”物联网应用的主力低功耗模式。调用PRCMLPDSEnter()进入。在此模式下，系统会发生深刻变化：

1. 电压降低：数字核心电压从1.2V降至0.9V。
2. 时钟停止：40MHz主晶振和PLL关闭，仅保留32.768kHz慢速时钟。
3. 逻辑掉电：大部分数字逻辑断电，应用处理器和网络处理器均被复位。
4. SRAM保持：最多256KB的SRAM可以按64KB为单元选择性保持。这是保存应用程序堆栈、全局变量等关键数据的关键。

• 功耗：这是其最大优势。在禁用网络和Wi-Fi子系统的情况下，芯片整体功耗可低至120µA。即使保持Wi-Fi连接并进行周期性唤醒（如监听信标），总系统电流也能低至700µA左右。
• 唤醒延迟：小于5ms。唤醒后，芯片从ROM引导加载程序开始执行，或者如果你预先设置了恢复信息，也可以跳转到SRAM中的指定地址继续执行。
• 唤醒源：支持三种方式唤醒：
  • 主机中断：来自网络处理器（NWP）的中断。
  • LPDS定时器：一个专用的、由32.768kHz时钟驱动的定时器。
  • GPIO：6个特定的GPIO引脚（GPIO 2, 4, 11, 13, 17, 24）上的电平或边沿变化。
• 适用场景：需要维持Wi-Fi网络连接、定时唤醒执行任务并上报数据的设备。例如，一个每5分钟上报一次数据的智能电表。

3.5 HIBERNATE（休眠）模式

这是最低功耗的模式，堪称“电子冬眠”。调用PRCMHibernateEnter()进入。在此模式下：

1. 全芯片掉电：整个SoC（包括MCU、NWP、SRAM）完全断电，所有状态丢失。
2. 仅存的生命体征：只有休眠控制器、32.768kHz时钟、RTC计数器以及两个32位的片上保持寄存器（OCR）由输入电源直接供电。
3. 超低功耗：典型电流仅4µA，这包括了RTC的运行功耗。
4. 唤醒即重启：唤醒后，芯片执行完整的冷启动流程，从Flash重新加载程序。

• 唤醒延迟：小于10ms（主要是重启和程序加载的时间）。
• 唤醒源：仅支持RTC定时器或上述6个特定GPIO。
• 适用场景：适用于对续航要求极端苛刻，且任务间隔非常长（如每小时、每天甚至更久）的应用。例如，野外环境监测传感器，或者需要运输数月才激活的物流追踪器。两个OCR寄存器可以用来保存关键的唤醒计数或状态标识符，帮助程序在重启后判断上下文。

3.6 模式对比与选型速查表

为了更直观地对比，我将关键信息整理成下表：

实操心得：在实际项目中，我通常将LPDS作为主力低功耗模式。它的功耗足够低，且能保持Wi-Fi连接和SRAM数据，唤醒速度也能满足大多数物联网应用（秒级或分钟级响应）。HIBERNATE则用于“运输模式”或极端省电场景。尽量避免使用DEEPSLEEP，直接使用LPDS是更简单可靠的选择。

4. PRCM API实战：从零构建一个低功耗传感器节点

理论说得再多，不如一行代码。现在，我们假设要设计一个智能温湿度传感器节点，它每5分钟测量一次环境数据，并通过Wi-Fi发送到云端，其余时间尽可能保持低功耗。我们将使用LPDS模式来实现。

4.1 系统初始化与基础配置

任何CC32xx应用在启动时，都应首先调用MCU初始化函数。这个函数会设置一些必要的芯片级配置。

#include "prcm.h" #include "hw_memmap.h" void BoardInit(void) { // 1. 初始化MCU的强制配置 PRCMCC32xxMCUInit(); // 2. 配置系统时钟（通常SDK的启动代码已处理，此处示意） // MAP_PRCMCC3200MCUInit(); // 如果是CC3200 // 3. 初始化你的外设，比如I2C用于传感器，UART用于调试 // InitI2C(); // InitUART(); }

4.2 配置LPDS唤醒源与SRAM保持

进入LPDS前，我们必须告诉芯片两件事：1) 什么事件能唤醒我？2) 哪些内存数据需要保留？

配置定时器唤醒：我们的需求是每5分钟唤醒一次。32.768kHz时钟的滴答周期是1/32768 ≈ 30.5微秒。5分钟就是300秒，所需的滴答数 = 300 / (1/32768) = 300 * 32768 = 9,830,400。

void ConfigureLPDSWakeup(void) { // 启用LPDS定时器作为唤醒源 PRCMLPDSWakeupSourceEnable(PRCM_LPDS_TIMER); // 设置唤醒间隔为5分钟（以32.768kHz时钟滴答数为单位） // 300秒 * 32768 Hz = 9,830,400 ticks PRCMLPDSIntervalSet(300 * 32768); // 如果你想同时支持GPIO唤醒（比如按键触发），可以这样配置： // PRCMLPDSWakeupSourceEnable(PRCM_LPDS_GPIO); // 选择GPIO2，下降沿唤醒（假设按键按下为低电平） // PRCMLPDSWakeUpGPIOSelect(PRCM_LPDS_GPIO2, PRCM_LPDS_FALL_EDGE); }

配置SRAM保持：我们希望全局变量和堆栈在睡眠时不被清除。CC32xx的SRAM分为4列，每列64KB。通常，我们保持所有列。

void ConfigureSRAMRetention(void) { // 启用所有4列SRAM在LPDS模式下的保持功能 unsigned long ulAllCols = PRCM_SRAM_COL_1 | PRCM_SRAM_COL_2 | PRCM_SRAM_COL_3 | PRCM_SRAM_COL_4; PRCMSRAMRetentionEnable(ulAllCols, PRCM_SRAM_LPDS_RET); // 注意：如果你非常清楚你的变量、堆栈只分布在某几列SRAM， // 可以只保持那几列，以略微降低功耗。但通常保持全部更省心。 }

4.3 设置LPDS恢复信息（可选但关键）

LPDS唤醒后，芯片默认从ROM引导加载程序开始执行，这会导致你的整个程序重新从头运行。为了做到“无缝”唤醒，即唤醒后从进入LPDS的地方继续执行，我们需要在进入前设置恢复信息。

// 这是一个在进入LPDS前调用的函数 void EnterLPDSMode(void) { // 声明两个变量，用于存储当前的栈指针和程序计数器 // 注意：这里需要一点内联汇编或编译器内置函数来获取真实值 // 以下是一种典型实现（具体取决于编译器） // 假设我们使用__current_sp()和__current_pc()来获取（需查看编译器手册） // unsigned long ulStackPtr = __current_sp(); // unsigned long ulProgCntr = __current_pc(); // 更常见且可移植的做法是，设置一个固定的恢复函数。 // 唤醒后，Bootloader会跳转到这个函数执行。 // 我们需要在进入LPDS前，将这个函数的地址告诉PRCM。 // 例如，我们定义一个恢复函数 // void LPDS_ResumeHandler(void); // 设置恢复信息：栈指针可以设置为系统栈顶，程序计数器设置为恢复函数地址 // 这里的 0x20000000 是SRAM起始地址，0xXXXX是LPDS_ResumeHandler的函数地址 // PRCMLPDSRestoreInfoSet(0x20000000 + 0x1000, (unsigned long)&LPDS_ResumeHandler); // 然而，在TI的CC32xx SDK中，通常提供了更高级的框架（如PowerCC32XX模块） // 来自动处理上下文保存和恢复。手动操作需要对内存布局和启动流程有很深理解。 // 对于初学者，建议先使用最简单的“唤醒即重启”模式，在main()函数开始处判断唤醒原因并恢复状态。 // 因此，这里我们先不设置恢复信息，让系统唤醒后从main()重新开始。 // 我们通过查询唤醒原因和利用保持的SRAM数据来恢复上下文。 // 进入LPDS PRCMLPDSEnter(); // 执行到此，芯片已进入LPDS。下一行代码将在唤醒后执行（如果设置了恢复信息）。 // 如果没设置，则不会执行到这里，而是重启。 }

重要提示：手动设置PRCMLPDSRestoreInfoSet进行“无缝”恢复是一项高级技巧，涉及栈和寄存器的保存/恢复，极易出错。TI的TIRTOS或某些SDK示例中的Power模块已经封装了这套复杂逻辑。在量产项目中，强烈建议使用TI官方提供的电源管理框架，而不是自己手动操作。对于我们的示例，我们采用更稳健的“唤醒即重启，通过状态恢复”的策略。

4.4 完整的应用流程与状态恢复

基于“唤醒即重启”的策略，我们设计以下流程：

// 在SRAM中定义一个保持的结构体，用于保存关键应用状态 // 使用 __attribute__((section(\".retention\"))) 或类似方式确保其位于可保持的SRAM区域 // 具体方法请参考编译器链接脚本和TI SDK指南 typedef struct { uint32_t wakeupCount; float lastTemperature; float lastHumidity; uint8_t wifiConnectedFlag; } AppState_t; // 假设通过链接器脚本，这个变量被分配到了可保持的SRAM区域 extern AppState_t g_appState __attribute__((section(\".retention\"))); int main(void) { // 1. 硬件初始化 BoardInit(); // 2. 判断本次启动是上电复位，还是从LPDS唤醒？ unsigned long resetCause = PRCMSysResetCauseGet(); if (resetCause == PRCM_LPDS_EXIT) { // 从LPDS唤醒 // 3. 获取LPDS唤醒原因，判断是定时器到点还是GPIO触发 unsigned long wakeCause = PRCMLPDSWakeupCauseGet(); if (wakeCause & PRCM_LPDS_TIMER) { // 定时器唤醒，执行周期性任务 printf(\"Woke up from LPDS by timer. Count: %lu\\n\", g_appState.wakeupCount); // 恢复之前的网络连接状态（如果保持） if(g_appState.wifiConnectedFlag) { // 快速重连Wi-Fi } // 读取传感器数据（使用之前初始化的外设？注意：外设需要重新初始化！） // 因为LPDS会复位处理器和外设，所以必须重新初始化所有外设。 ReinitPeripherals(); // 重新初始化I2C, GPIO等 float temp = ReadTemperature(); float humi = ReadHumidity(); g_appState.lastTemperature = temp; g_appState.lastHumidity = humi; // 发送数据到云端 SendToCloud(temp, humi); g_appState.wakeupCount++; } else if (wakeCause & PRCM_LPDS_GPIO) { // GPIO唤醒，可能是用户按键，执行相应操作 printf(\"Woke up from LPDS by GPIO.\\n\"); // 例如，进入配置模式 EnterConfigMode(); } } else { // 冷启动（上电或HIBERNATE唤醒） printf(\"Cold boot.\\n\"); // 初始化应用状态结构体 memset(&g_appState, 0, sizeof(AppState_t)); // 进行完整的系统初始化：Wi-Fi连接、外设初始化等 InitAllPeripherals(); ConnectToWiFi(); g_appState.wifiConnectedFlag = 1; } // 4. 为下一次睡眠做准备 ConfigureLPDSWakeup(); ConfigureSRAMRetention(); // 5. 进入LPDS前，保存必要状态（除了已在保持结构体中的） // 例如，可以关闭外设电源，将GPIO设为低功耗状态等。 PrepareForLowPower(); printf(\"Entering LPDS...\\n\"); // 短暂延时，让串口打印完成（在实际低功耗应用中应关闭调试输出） DelayMs(100); // 6. 进入低功耗深度睡眠 PRCMLPDSEnter(); // 代码不会执行到这里。下次唤醒后，又从main()开始。 while(1); }

4.5 HIBERNATE模式使用示例

对于需要更长时间休眠的场景，比如每天只上报一次数据，HIBERNATE是更好的选择。由于HIBERNATE会丢失所有状态，两个OCR寄存器就显得尤为重要。

void EnterHibernateForOneDay(void) { // 1. 将关键信息保存到OCR寄存器（例如，一个启动计数器） static uint32_t bootCount = 0; bootCount++; PRCMOCRRegisterWrite(0, bootCount); // 写入OCR0 // 2. 配置RTC定时器唤醒（24小时） // 24小时 = 86400秒， tick数 = 86400 * 32768 = 2,831,155,200 // 注意：PRCMHibernateIntervalSet 参数是48位，需要64位整数 unsigned long long oneDayTicks = 86400ULL * 32768ULL; PRCMHibernateIntervalSet(oneDayTicks); // 3. 启用RTC作为唤醒源 PRCMHibernateWakeupSourceEnable(PRCM_HIB_SLOW_CLK_CTR); // 4. 也可以配置GPIO唤醒作为备用（比如手动唤醒按钮） // PRCMHibernateWakeupSourceEnable(PRCM_HIB_GPIO2); // PRCMHibernateWakeUpGPIOSelect(PRCM_HIB_GPIO2, PRCM_HIB_FALL_EDGE); printf(\"Entering Hibernate for 24 hours...\\n\"); DelayMs(100); // 等待打印完成 // 5. 进入休眠 PRCMHibernateEnter(); // 芯片断电。下次唤醒是24小时后，从复位向量开始执行。 } int main(void) { BoardInit(); // 检查是否从HIBERNATE唤醒，并读取OCR中的值 if (PRCMSysResetCauseGet() == PRCM_HIB_EXIT) { uint32_t lastBootCount = PRCMOCRRegisterRead(0); printf(\"Woke from Hibernate. Previous boot count: %lu\\n\", lastBootCount); } else { printf(\"Cold boot or other reset.\\n\"); } // ... 执行你的主要任务 ... // 任务完成，进入24小时休眠 EnterHibernateForOneDay(); while(1); }

5. 低功耗设计实战技巧与避坑指南

掌握了API只是第一步，在实际项目中实现稳定的超低功耗，还需要注意以下这些细节，很多都是文档里不会写的“坑”。

5.1 外设与GPIO的功耗管理

未使用的外设：在进入低功耗模式前，务必禁用所有不必要的外设时钟。即使外设不工作，它的时钟树和部分逻辑可能仍在消耗电流。使用PRCMPeripheralClkDisable函数，并在RUN_MODE、SLP_MODE、DSLP_MODE所有标志位上都禁用。

GPIO配置：这是最常见的“功耗漏洞”。

• 悬空引脚：未连接（浮空）的输入引脚会因感应噪声而产生振荡电流。务必将其设置为输出低电平或带上拉/下拉的输入模式。
• 输出引脚状态：驱动外部元件的GPIO，在睡眠前要确保其状态不会导致外部电路产生漏电流。例如，驱动一个LED的引脚，睡眠时应设为低电平（如果LED阳极接VCC）或高阻态。
• 内部上拉/下拉：根据外部电路决定是否启用。如果外部已有上拉电阻，再启用内部上拉会造成分压和额外电流。

5.2 测量与验证功耗

不要相信数据手册的典型值，一定要实测！搭建一个简单的测试电路，使用高精度万用表或电流探头测量VBAT引脚的电流。

1. 分阶段测量：分别测量ACTIVE、IDLE（空循环）、SLEEP、LPDS、HIBERNATE模式下的电流。
2. 关注峰值和平均电流：Wi-Fi发射时的峰值电流可能高达200mA+，但平均电流取决于发射占空比。使用示波器的电流测量功能观察动态波形。
3. 排除外部因素：断开所有不必要的外部电路，仅测量核心板的电流，以确定是否是外部元件导致的高功耗。

5.3 常见问题排查清单

5.4 软件架构建议

对于复杂的物联网应用，建议采用事件驱动的软件架构，而不是简单的while(1)轮询。

1. 主循环精简：主循环应快速检查事件标志，无事可做时立即进入SLEEP或LPDS。
2. 使用RTOS：考虑使用TI-RTOS或FreeRTOS。它们的空闲任务（Idle Task）会自动在系统空闲时调用低功耗API，管理起来更高效。
3. 分层进入低功耗：不要每次都直接进入最深的LPDS。在短时间等待（如几十毫秒）时，使用SLEEP模式可以获得更快的响应。根据下一个预定事件的时间，动态选择进入SLEEP还是LPDS。
4. 状态机管理：使用状态机清晰管理设备的运行、连接、测量、发送、睡眠等各个状态，确保状态转换时资源被正确释放和配置。

电源管理是嵌入式系统，尤其是物联网设备开发的精髓所在。它要求开发者具备硬件、软件和系统级的综合视角。从理解CC32xx的PMU架构开始，到熟练运用PRCM API控制四种低功耗模式，再到通过精细的外设管理和状态保存实现极致的续航，每一步都需要深思熟虑和反复测试。记住，数据手册上的µA级电流是一个理想值，你的实际功耗取决于整个系统的设计。多测量，多验证，从每一次“踩坑”中积累经验，你就能打造出真正满足市场续航要求的可靠产品。