做电池供电的 IoT 产品，最怕的不是功能做不出来，而是产品做出来、电池却撑不过一个冬天。最近看到 Nordic 新芯片的规格数据，说休眠电流标到了 50 nA 以下，连续放一年才消耗 0.438 mAh。这个数字刚看到的时候，我是按了两遍计算器的——50 纳安是什么概念？0.438 毫安时又是怎么算出来的？今天不聊新闻稿，就从硬件工程师做低功耗产品的角度，把这个数字拆开讲清楚：先搞清楚它是什么量级，再说芯片怎么做到的，然后回到实际项目里怎么算电池寿命、怎么复现这个数据，最后顺手聊聊把 NimBLE 这种开源协议栈移植到 Nordic 芯片上时，真正会踩到哪些坑。

1. 先看这个数字有多夸张：50nA 是什么概念

1.1 用生活化的类比理解 50 nA

先说结论：50 纳安不是一个"小"电流，它是一个在工程上几乎可以忽略不计的电流。1 安培是 10 亿纳安，50 nA 等于 0.00000005 A。普通 LED 指示灯的工作电流大概 5 mA，这颗芯片的休眠电流相当于它的十万分之一；一节 5 号碱性电池的自放电电流都不止这个数。

我见过很多朋友第一次接触低功耗项目时，对 nA 没有体感。这里给一个直觉式子：如果你把一个 1 µA 的电流比作一天流一滴水，50 nA 就相当于一个半月才流一滴。用万用表的普通毫安档去测这种电流，表笔接口的接触电阻、表内采样电阻的温漂，都可能比被测信号大几个数量级。所以标题里"不到 50 nA"这个数字，不是靠普通测试设备能轻松复现的，后面我会专门讲测试坑。

1.2 0.438 mAh 是怎么算出来的

这个数字其实是个很简单的乘法。50 nA 换算成 mA 是 0.00005 mA，一年是 365 × 24 = 8760 小时，两者一乘：

• 0.00005 mA × 8760 h = 0.438 mAh

就这么简单。也就是说，如果一颗电池只给这颗芯片的休眠状态供电，理论上一年也就贡献 0.438 毫安时。拿一颗常见的 CR2032 纽扣电池来比，额定容量大概 220 到 240 mAh，0.438 mAh 相当于一年动用不到 0.2% 的容量。这个量级已经远远低于电池自身的自放电损耗，也就是说"芯片休眠耗电"在电池寿命模型里基本可以当成零来处理。

但这里必须强调一个边界：0.438 mAh 只是"纯深度休眠"的理论值。真实系统里还有唤醒、广播、连接、传感器采样、供电链路损耗、PCB 漏电、电池自放电，后续实际项目部分我会把完整的 Power Budget 算法写出来。

1.3 为什么休眠电流是电池设备的命门

对 IoT 设备来说，工作状态通常只占极短时间。以资产追踪标签为例，假设每 30 分钟上报一次位置，每次连接加测量总共 100 毫秒，那么一天 24 小时里真正工作的累计时间只有 4.8 秒，占比不到十万分之六。剩下 99.99% 的时间芯片都在休眠。

这时候整机平均电流几乎完全由休眠电流决定。我们做个对比：同一颗 225 mAh 的电池，如果休眠电流分别做到 1 µA 和 50 nA，单看休眠耗电，前者一年多耗 8.76 mAh，后者只有 0.438 mAh——差出整整 20 倍。在低上报频率的场景里，这个差距直接决定产品是"一年一充"还是"三年不换电池"。这也是芯片厂商拼命把休眠电流往下压的核心原因：唤醒瞬间的功耗大家都差不太多，能拉开差距的恰恰是平时没人注意的"待机抠门"能力。

2. 从架构层面拆解：这颗芯片凭什么做到 50 nA 级

2.1 System OFF 与 System ON 的差异

提到休眠，必须先分清两个概念：System ON 和 System OFF。

System ON 模式下，CPU 可以处于睡眠，但内部稳压器、RAM、外设总线、RTC 这些模块大多还供着电。虽然外设时钟关掉了，静态漏电依然存在，典型电流是微安级别。很多 SoC 标称的"睡眠电流几微安"，指的就是这种状态。

System OFF 则相当于给芯片来了一个"硬件级断电"。内部大部分电源域被切断，RAM 不再保持数据，时钟停振，只保留极少数唤醒逻辑。这个模式下的目标电流才可能走到 nA 级。所以看到 50 nA 这个数据时，第一反应应该是：这颗芯片的深度关断能力做得极其彻底。值得提醒的是，如果片子还要同时维持 RTC 跑日历、RAM 保持数据，电流天然会上去，也就很难做到 50 nA 这个量级了。选型时必须先想清楚：你到底是要"纯掉电待机"，还是要"定时器随时能醒"。

2.2 纳安级关断的硬件设计关键

芯片内部要做到纳安级漏电，靠的不是某一项技术，而是一整套电源管理策略。

第一是电源域划分。现代低功耗 SoC 会把射频前端、基带处理器、Flash、SRAM、模拟外设分成独立的电源域，深度关断时用片上电源开关全部断开，只留一个极小面积的"唤醒盒"常供电。这个"唤醒盒"只包含引脚检测、少量电平转换和系统复位逻辑，面积越小，静态漏电越低。

第二是管脚漏电控制。很多人忽略 I/O 口的漏电有多可怕。如果某个 GPIO 在休眠时处于浮空状态，输入端的保护二极管和寄生晶体管就可能形成弱导通回路，单个引脚漏掉一两百纳安很正常，几十个引脚加起来就是微安级。所以深度关断模式要求所有 GPIO 必须被钳位到确定的电平，要么内部上拉，要么配置成模拟外设并关断，要么由外部电路固定电平。这其实是实际项目中"芯片标称很漂亮，板子实测翻车"的最大来源之一。

第三是工艺与温度的关系。晶体管亚阈值漏电跟温度呈指数关系。室温下能做到 50 nA，到 60°C 的环境里可能翻两三倍，85°C 下再翻几倍。所以芯片规格书里的 nA 级数字，通常都是在 25°C 附近的典型值。做户外设备、车载设备时，Power Budget 必须按最高工作温度下的泄漏电流来留余量。

2.3 保持唤醒能力需要多少代价

深度关断不意味着"谁也喊不醒"。芯片必须保留几条唤醒路径，常见的有 GPIO 边沿唤醒、内部低频定时器唤醒、电源比较器唤醒。Nordic 系芯片还有 NFC 唤醒这种比较讨巧的设计：用手机靠近 NFC 天线就能产生一个内部事件把系统拉起来，不需要额外按键，也不用消耗待机电流去监听无线信号。

但是要注意，所有这些唤醒功能都要消耗静态电流。GPIO 检测逻辑比较简单，做到 nA 级还有可能；低频振荡器+RTC 的典型电流一般在几百纳安到 1 µA 左右，如果要"每天定时醒来"同时又宣称 50 nA，那多半意味着 RTC 没有常开，而是采用更省电的极低频时钟或者干脆靠外部事件唤醒。工程上找平衡点时，我习惯把需求拆成两类：需要自动定时唤醒的，按 µA 级待机来设计；接受外部触发唤醒的，才有资格享受 nA 级红利。

2.4 和上一代产品放在一起看差距

表格里的数字更能说明问题。以 Nordic 现有的公开低功耗蓝牙 SoC 路线作为参照，常见规格大致是这样：

从 300 nA 压到 50 nA，是接近一个数量级的跨越。在电池寿命模型里，这个"底数"变了，意味着很多原本需要大电池或者频繁换电池的产品形态可以重新设计。尤其是医疗贴片、智能标签、无源传感器节点这类对体积极度敏感的设备，50 nA 带来的收益不是续航多几个月，而是整个产品逻辑从"必须换电池"变成"一次性用三五年"。

3. 实际项目中，50 nA 意味着什么：电池寿命估算与 Power Budget

3.1 用一颗纽扣电池估算理论极限

拿到 50 nA 的规格，放到真实项目里怎么用？先从极限算起。

假设你用一颗 CR2032，额定容量 220 mAh。纯休眠且只有芯片自身耗电，一年 0.438 mAh，算下来理论寿命是 220 ÷ 0.438 ≈ 502 年。这个数字看起来荒谬，是因为它根本没有意义——没有任何锂电池或纽扣电池能真的放 500 年。电池内部会自放电，CR2032 每年的自放电率大约 1% 到 2%，也就是每年自损 2 到 4 mAh，比芯片休眠耗电高出一个数量级。

所以从系统角度看，50 nA 的芯片配上纽扣电池，"寿命瓶颈"完全转移到了电池化学体系本身。换句话说，你把芯片休眠功耗再砍五倍，整机续航也不会有什么变化，因为电池自己每年都要漏掉同样多的电。这是做 Power Budget 时必须理解的第一层逻辑：当芯片休眠电流低到电池自放电之下，续航优化目标就不再是"继续压芯片电流"，而是选择自放电更低、保质期更长的电池体系。

3.2 平均电流计算的完整示例

下面给一个可以直接套用的计算框架。假设要做一款资产追踪标签：

• 上报周期：30 分钟一次
• 每次上报工作时间：100 ms，期间平均电流 10 mA（射频发射+传感器）
• 休眠电流：50 nA
• 电池：CR2032，220 mAh

先算每天工作耗电。每天上报次数：24 × 60 ÷ 30 = 48 次。每次工作 100 ms，耗电为 10 mA × 0.1 s = 1 mAs。1 mAs 换算成 mAh，除以 3600，即 0.000278 mAh。48 次合计 48 × 0.000278 ≈ 0.0133 mAh/天。

再算每天休眠耗电。每天 86400 秒，减去 4.8 秒工作时间，还剩 86395.2 秒。50 nA 是 0.00005 mA，休眠耗电为 0.00005 mA × (86395.2 ÷ 3600) h ≈ 0.0012 mAh/天。

两者相加，每天平均耗电约 0.0145 mAh。一年 365 天，总计约 5.3 mAh。用 220 mAh 电池看，理论寿命约 41 年。这个数字还是会被电池自放电封顶，实际工程里如果选到自放电较小的电池，系统寿命做到五到八年是合理的。

如果把休眠电流改成 3 µA，其他不变，每天休眠耗电变为 0.00005 mA 的 60 倍，即 0.072 mAh/天，一年新增 26 mAh 左右，理论寿命立刻掉到 7 年附近。高频上报系统里工作耗电占大头，休眠电流差点无所谓；但低频上报系统（比如一天一次）里，休眠电流直接成了电池寿命的天花板。

3.3 别忽略板级漏电：PCB、电容、焊接残留

芯片在厂家测试板上能到 50 nA，不代表你的产品也能到。板级漏电通常是"缩小芯片规格差距"时最大的隐形杀手。

PCB 表面的绝缘电阻不是无限大，普通 FR-4 板材在潮湿环境下表面电阻可能降到几十兆欧，相邻走线之间的电压差哪怕只有 3 V，漏电流就可能到几百纳安。助焊剂残留遇到湿度会形成弱电解质桥；去耦电容里的 X7R、Y5V 本身漏电比 C0G 大；ESD 保护管的结漏电在高温下也不可小觑。SMT 不洗板、用错清洗剂，都可能让整板休眠电流比芯片高一个数量级。

所以做超低功耗产品时，PCB 设计要主动留出"漏电预算"：禁止在休眠网络上跨接高阻走线，去耦电容优先选低漏电的 C0G/Class 1 介质，敏感节点周围铺地隔离，必要时整板做三防漆处理。这些措施不复杂，但每一项都能防止你半夜对着示波器怀疑人生。

3.4 温度对漏电的影响必须留余量

半导体漏电和温度的关系，可以用"每升温 10°C，漏电翻倍"的粗略规则来感受。不是说所有器件都严格按这个规律走，但用来做前期估算足够。

假设芯片在 25°C 实测 50 nA，到了 55°C 环境温度下，芯片结温可能到 65~75°C。按翻倍估算，漏电流可能到 200~400 nA。再叠加 PCB 表面漏电、电容漏电，系统级休眠电流到 1 µA 都不奇怪。工程计算时，我会同时算三组数：25°C 典型值用于画饼，55°C 正常值用于设计，85°C 极限值用于可靠性评估。

4. 低功耗蓝牙协议栈移植：当你在 Nordic 芯片上跑 NimBLE 时要关注什么

4.1 为什么有人放着现成协议栈不用，非要移植 NimBLE

Nordic 自家有 SoftDevice 协议栈，闭源发布，和 SDK 集成度高。那为什么还有人要把 NimBLE 这种开源协议栈移植到 Nordic 芯片上？

原因无非三类。第一，NimBLE 是 Apache 2.0 开源协议，商用友好，可裁剪性强，不像 SoftDevice 那样是一个"黑盒子"。第二，跨平台需求。很多团队同一个 BLE 协议栈要跑在不同厂商芯片上，NimBLE 有标准的硬件抽象层，换芯片只需改移植层。第三，进入维护期的项目需要长期可控。SoftDevice 的升级节奏和厂商支持周期不完全由项目自己决定，NimBLE 则可以锁定版本长期维护。

不过移植不是"把代码编译一遍过"的事。NimBLE 对下要跟芯片的时钟、定时器、随机数、加密、射频中断打交道，对上要提供符合操作系统抽象层（BleNPL）的原语。这里提到的"厂商函数"，具体到 Nordic 平台上，指的就是 SDK 和 nrfx 驱动库里那些 nrf_xxx 系列接口。

4.2 移植时需要对接哪些 Nordic 厂商函数

我按功能模块列一份真实项目里会碰到的函数清单，这些不是全部，但覆盖了常见需求：

NimBLE 的时间管理需要系统 tick 支撑。在 Nordic 平台上通常把 RTC 作为底层 tick 源，通过 nrf_rtc 配置好周期中断，让协议栈在广播接入、连接事件、扫描窗口这些时间点准时唤醒。这个过程不是简单的"调用一个函数"，而是要跟芯片的低功耗模式配合，否则要么系统醒不过来，要么为了等事件白白放宽睡眠时钟。

一个常见做法是把 NimBLE 的 ble_npl_time 层和 Nordic 的 RTC 中断绑定，用事件回调机制驱动协议栈调度。中断服务函数里只做置标志、唤醒等轻量操作，重活放到主循环或任务上下文处理。我在移植时还习惯单独做一个"电源管理模块"，统一管理休眠前的 GPIO 状态、外围设备断电时序、RTC 比较值设置，避免每次进入休眠前都在主代码里打补丁。

4.3 移植踩坑清单

结合我自己移植 NimBLE 到 Nordic 平台的经验，以下几个坑是高频出现的。

第一个坑是 Flash 存储规划。Nordic 芯片用内部 Flash 存协议栈参数、绑定信息、MAC 地址。NimBLE 有自己的配置存储机制，同时 Nordic SoftDevice 可能也占用特定地址段。两者混用前，必须确认 Flash 布局不冲突，还要注意页擦写次数。BLE 配网绑定的信息会频繁擦写，选地址时要避开程序代码段，并且预留磨损均衡的空间。

第二个坑是中断优先级。BLE 协议栈对事件响应非常敏感，射频中断稍有延迟就可能丢连接事件。Nordic 的 SoftDevice 本身把射频相关中断放在很高优先级，NimBLE 裸机移植时，也要确保协议栈相关中断优先级足够高，同时不能长期关闭全局中断。很多丢包、广播时断时续的问题，最终都查到"主循环里关了太久中断"这个原因上。

第三个坑是 32.768 kHz 晶振。低功耗蓝牙的协议栈调度严重依赖稳定低频时钟。如果用内部 RC 振荡器代替外部晶振，精度不够会导致连接事件漂移、平均电流上升。我在一个项目里试过用内部 RC 省成本，结果连接间隔抖动量明显变大，电池寿命实测也比规格书估算短了两成。内部 RC 省下来的几毛钱，最终都赔给了电池和售后。

第四个坑是低功耗唤醒与广播间隔的匹配。NimBLE 的广播任务如果不能和系统休眠周期对齐，系统会多醒若干次。每次唤醒就算只多 2 ms、平均多耗 5 mA，一小时醒 60 次，一年多耗的电也不是小数目。正确做法是把广播事件和 RTC 唤醒时间对齐，用"散弹枪式的快速唤醒窗口"替代固定周期硬扫描，把无效唤醒降到最低。

5. 实战记录：一次休眠电流实测踩坑与排查

5.1 测试环境与仪表的选择

nA 级电流不是普通万用表能干的事。普通万用表的电流档分辨率一般在 0.1 µA 甚至 1 µA，测 50 nA 时读数不是 0 就是噪声。要测 nA 级，至少要用 pA 级分辨率的高精度源表或者静电计，比如 Keithley 2450、6517B 这类设备；没有台机的话，也可以考虑带高精度电流档的台式万用表加屏蔽测试盒。

同时要注意测试方法。把电流表串联进电源回路，是直接法，简单但是电流表本身会有负载电压，影响芯片实际供电电压；间接法通常是在供电回路上串联一个已知阻值的采样电阻，通过测电阻两端电压换算电流。对 50 nA 级别，如果采样电阻取 10 kΩ，压降是 0.5 mV，完全可接受。实际操作中我更推荐用"先让设备跑正常唤醒流程，再跳到深度休眠，然后用高精度表监控跳变曲线"的方式，这样能看到唤醒与休眠切换瞬间的真实电流轮廓。

5.2 实测中遇到的几个常见坑

我踩过最典型的坑是在面包板上测低功耗电流。面包板的金属簧片之间接触电阻不稳定，湿度高的时候还会产生电化学电流，测出来的休眠电流直接比芯片规格高两个数量级。后来改成焊接的测试小板，问题才消失。另外一个高频坑是调试器没断开。JTAG/SWD 调试器只要还连着，目标芯片的调试端口就会保持一小部分供电逻辑，实测电流多出几个微安都很正常。测低功耗之前，必须把调试器物理拔出，或者把调试口通过跳线断开。

还有一个坑是电容放电时间常数。板上有大容量去耦电容时，切到休眠状态后，电流表读数不会立刻稳定，因为电容还在慢慢放电。我遇到过读数要等十几分钟才能降下来的情况。这时别急着调代码，先把待机时间拉长或者把大电容临时断开再看数据。

5.3 我的测试流程建议

把经验沉淀成流程，可以这么走：

• 第一步，测最小系统。只焊芯片、晶振、必要去耦电容，烧一个只进休眠的空程序，测芯片本身能达到的最低电流。这一步是把"芯片能力"和"板子能力"分开，后续所有数据都跟它对比。
• 第二步，逐步增加外设。每加一个模块测一次，看谁把休眠电流抬高了。有时候罪魁祸首是一颗不起眼的运放，而不是主芯片。
• 第三步，测完整产品在不同温度下的休眠电流。用高低温箱扫 25°C、40°C、60°C、85°C，记录漏电上行曲线，用于寿命模型。
• 第四步，做长时间电压跌落法验证。如果条件有限，可以在测试板上并联一颗大电容，记录 24 小时电容电压变化，用 dU/dt 反推平均漏电。这个方法不用高精度电流表，但可以验证系统长期趋于稳定的电流。

这套流程下来，基本能把"规格书 50 nA、板子实测 300 nA"这类问题定位到具体环节。别一上来就怪芯片，多半是板级或者测试方法的问题。

6. 我在实际项目中得到的体会

做了几年低功耗产品，我的体会是：芯片的 nA 级参数是"入场券"，不是"保险单"。它决定了你的产品有资格冲击三五年不换电池的形态，但最终能不能撑到那一天，还要看板级设计、测试方法和电池选型是否同样讲究。50 nA 这个数字确实厉害，可它厉害的地方不是让你在新闻稿里感慨，而是让真正的系统设计者可以放开手脚去优化成本、缩小体积、延长维护周期。

如果你正准备拿这颗芯片做新产品，我的建议是先别急着选电池，拿规格书里的休眠电流、唤醒时间、连接峰值电流，按真实业务场景列一张 Power Budget 表，把 25°C、55°C、85°C 三行都算出来。等板子打样回来，再用我说的流程把实测数据填进去对比。如果实测跟理论差太多，优先查调试器、查 GPIO 浮空、查板级漏电，而不是换芯片。毕竟再强的芯片，也扛不住一块处理不当的 PCB。