LPBAM这个低功耗功能，不懂它低功耗设计等于白做-凡亿课堂

做低功耗产品的工程师大概都有过这种经历：费了半天劲把芯片选到Stop 2模式，电流好不容易压到3μA以下，结果发现一个问题——传感器数据还得采啊。于是每秒唤醒一次CPU，读I2C、采ADC、存数据，一轮下来电流直接飙到几百μA，平均一算，待机时间砍掉大半。

问题出在哪？CPU醒了。每次唤醒，内核时钟恢复、外设重新初始化、中断响应，这些动作本身就要吃好几个mA。如果传感器采样频率不高，比如加速度计32Hz，其实每次采集的数据量就几个字节，CPU干这件事属于"杀鸡用牛刀"。

ST在STM32U5上搞了个东西叫LPBAM（Low Power Batch Autonomous Mode），就是专门解决这个矛盾——让外设在CPU深度休眠时自己完成数据采集和传输，CPU全程不醒。

图1：STM32低功耗开发板与电流测量

LPBAM到底是什么

LPBAM全称Low Power Batch Autonomous Mode，翻译过来就是"低功耗批量自主模式"。核心思路：CPU睡觉，外设自己干活。

具体来说，在Stop 2模式下（CPU关闭、大部分时钟停止），ADC、I2C、SPI、LPTIM这些外设可以通过LPDMA（低功耗DMA）自主完成数据采集和搬运。整个流程不需要CPU介入：LPTIM定时触发→I2C读传感器→LPDMA把数据搬进SRAM→存够一组后触发中断唤醒CPU。

功耗差多少？同样的传感器采集任务，传统方式每秒唤醒CPU一次，平均电流可能200μA起步；用LPBAM，CPU全程Stop 2，只有LPDMA和少量外设在跑，实测电流可以压到4~5μA。差了将近两个数量级。

图2：Stop模式下的电流波形分析

LPBAM怎么用：一条链路走完

LPBAM的使用方式跟普通DMA不太一样，它用的是"队列"（Queue）的概念。你把一组操作排成链，然后交给LPBAM引擎自动执行。

拿最常见的手环加速度计采集举例，典型链路是这样的：

第一步：配置LPBAM队列。告诉它I2C地址是0x19（LIS2DW12），要读的寄存器是0x28（OUT_X_L），读6个字节，存到SRAM的accel_buffer。

第二步：配置触发源。用LPTIM每31.25ms触发一次（32Hz），触发后自动执行上面的I2C读取+DMA搬运。

第三步：配置唤醒条件。比如数据攒够64组（2秒），或者加速度超过阈值，才触发中断唤醒CPU。

整个过程中CPU在Stop 2模式里睡得死死的，数据安安静静地躺在SRAM里，等CPU醒来直接处理就行。

关键代码就几行：启用LPBAM时钟→配置队列→配置触发源→进Stop 2模式。CubeMX2里可以直接图形化配置LPBAM链路，不需要手写寄存器。

哪些外设支持LPBAM

不是所有外设都能在Stop 2模式下自主运行。STM32U5上支持LPBAM的外设主要包括：

注意，这些外设之所以能在Stop 2下跑，是因为它们用的时钟源是LSI（32kHz低速内部RC）或LSE（32.768kHz外部晶振），不需要高速时钟。

图3：电池供电的IoT传感器设备

实测数据：传统方式 vs LPBAM

拿智能手表场景做个对比：加速度计32Hz持续采集，CPU每2秒醒一次处理数据。

当然这是理想计算，实际产品里还有屏幕、蓝牙、传感器本身的待机电流要算进去。但光MCU这一项，LPBAM就能省出一个数量级的功耗，差距是非常实在的。

有个容易忽略的点：LPBAM模式下SRAM是可以保持的，采集的数据直接写在SRAM里，CPU醒来后不需要重新初始化外设，处理完接着睡。这个"醒来→处理→再睡"的周期越短，平均功耗越低。

哪些芯片有LPBAM

目前ST只有STM32U5系列完整支持LPBAM，包括U575、U585、U5A5、U599等型号。STM32L4和L5虽然也有低功耗DMA，但不支持完整的LPBAM队列机制。如果你正在选型，做电池供电产品又需要持续采集传感器数据，U5几乎是唯一选择。

STM32U5的Stop 2模式带LPBAM实测功耗4~5μA，不带LPBAM的Stop 2也要2μA左右——但那是什么都不干的功耗。如果你需要持续采集数据，LPBAM让你在几乎同样的功耗水平下完成了工作，这才是它的价值所在。

低功耗设计不是把芯片往Stop模式一扔就完事了。CPU醒了就是功耗黑洞，能不让它醒就别让它醒。LPBAM就是干这个的——CPU睡你的，活我替你干。

登录后查看更多

LPBAM这个低功耗功能，不懂它低功耗设计等于白做