企业官网建设流程全解析

1. 从 PHY6270 的功耗账本看起：超低功耗 BLE SoC 究竟省在哪

样片回来第一件事不是点灯，是量电流。这是我做蓝牙 LE 6.1 超低功耗系统级芯片项目时雷打不动的习惯——PHY6270 这类超低功耗 BLE SoC，规格书上那些漂亮的微安数字，跟你板上实际跑出来的值，中间往往隔着一个数量级的差距。而有意思的是，这个差距通常不是芯片的锅，是设计者的锅。所以聊这颗芯片，我不打算从"它有多少 GPIO、主频多高"开始，那是最没信息量的部分。我想先聊它的功耗账本，因为"超低功耗"这四个字，才是这一类系统级芯片存在的全部理由。

先说清楚适用人群：如果你正在做电池供电的无线传感节点、可穿戴、电子价签、资产标签、遥控器，或者最近很热的电池供电端侧 AI 视觉模块，那这篇内容对你直接有用。如果你只是想做一块插着 USB 的开发板跑个点灯 Demo，那随便一颗 SoC 都行，超低功耗对你不构成约束条件。功耗这件事，只有在续航被用户拿放大镜看的产品里，才从"优化项"变成"生死线"。

提示：下面涉及的具体电流数值，我给出的都是这一类超低功耗 BLE SoC 的典型区间，用于建立量级感。PHY6270 的真实参数请以官方数据手册为准，不同批次、不同温度、不同供电电压下都会有出入。用典型值做架构决策，用实测值做最终验收，这两件事不能混。

1.1 三笔账：静态漏电、动态运行电流、射频突发电流

任何一颗 SoC 的电流消耗，都可以拆成三笔独立的账，这三笔账的量级差了三个数量级，所以优化顺序绝对不能搞反。

第一笔是静态漏电，也叫休眠电流。这是芯片在深度睡眠模式下，CPU 停摆、大部分电源域断电、只有 RTC 和极少量 RAM 保持时的电流。这一类芯片的合理区间在0.5 µA 到 3 µA之间。别小看这几微安，它是整个续航的地板——你后面所有的动态优化做得再好，也不可能低于这个数。很多项目一开始算出来"能用三年"，结果实测发现休眠电流是 30 µA 而不是 3 µA，三年的账瞬间变成三个月。

第二笔是动态运行电流，CPU 跑起来、外设时钟打开时的电流，通常在1.5 mA 到 5 mA每 MHz 的量级（取决于工艺和架构）。这笔账的特点是：它很大，但你完全可以控制它开多久。超低功耗设计的核心思路从来不是"让它跑得省"，而是"尽量别让它跑"。能用 DMA 搬的数据不要用 CPU 搬，能在硬件里算的 CRC 不要在软件里循环，能靠比较器唤醒的别让 ADC 一直转。

第三笔是射频突发电流，也是三笔里最大的。2.4 GHz 收发瞬间的峰值电流，0 dBm 发射功率下典型在5 mA 到 10 mA，接收状态在4 mA 到 8 mA。这笔账的特点是"高而短"：它只持续几百微秒到几毫秒，但如果你每秒触发一次，那平均下来就是几十微安。

把三笔账摆在一起看，你会发现一件反直觉的事：决定续航的往往不是射频，而是休眠电流和第二笔账的"开启时长"。我见过太多人把精力全花在调连接间隔上，结果板子上一个上拉电阻接错，或者一个 LDO 的静态电流没查，直接吃掉 20 µA，前面所有努力白费。

1.2 蓝牙 LE 6.1 在链路层上做了哪些省电的事

聊蓝牙 LE 6.1，得先把一件事说清楚：协议版本的迭代，对功耗的影响绝大多数发生在链路层和控制器，而不是应用层。你写 GATT 服务的方式，从 4.0 到 6.1 几乎没变；但底层链路管理的机制，一直在往"用更少的射频时间完成同样的信息交换"这个方向走。

拿几个实际影响功耗的机制举例。连接参数协商与从机延迟是省电的第一大杠杆，主机和从机约定连接间隔和从机可以跳过的连接事件数，让从机大部分时间可以关掉射频睡大觉。LE 功率控制允许链路两端根据实际信道质量动态调整发射功率，近距离通信时把功率降下来，直接省掉射频突发电流里最大的一块。**连接子速率（Connection Subrating）**这类机制则允许链路在某段时间内把连接间隔临时拉长，进一步压低平均电流。

蓝牙 LE 6.1 作为较新的核心规范版本，芯片厂商在宣传时通常会重点标注协议栈在链路管理效率、抗干扰与低功耗特性上的支持情况。但这里必须提醒一句：规范版本号和实际能省多少电之间没有直接公式，真正决定结果的是协议栈实现质量、双端设备的协商结果，以及你选的连接参数。同一个 6.1 芯片，配不同的手机，跑出来的功耗曲线可能差一倍，因为手机端的连接参数偏好完全不同。

所以选型时，我的建议是别只看"支持 LE 6.1"这个标签，而是去问清楚三件事：协议栈是 ROM 固化还是可配置的、连接参数协商时从机能不能提要求、低功耗模式下链路层是否支持自动维持。这三点比版本号实在得多。

1.3 什么时候该上这一类芯片，什么时候真的不该

超低功耗系统级芯片不是万能药，它有自己的甜区。判断标准很简单：看你的产品是否长期处于"沉睡"状态，只在极少数时刻被事件触发。

如果是,那这一类芯片的价值就能充分发挥。资产标签、无线传感器、门磁、温湿度记录仪、遥控器、电子价签，这些场景的共同点是：99.9% 的时间在睡觉，剩下 0.1% 的时间在干活。芯片的休眠电流直接决定续航，射频只负责把事件上报。

反过来，如果你的应用需要持续音频流、持续图像流、持续高速数据采集，那这颗芯片就不对路。持续传输意味着射频长期在线，平均电流会直接跳到毫安级，再怎么优化也扛不住纽扣电池。这种场景要么接受更大的电池，要么换方案——比如本地处理、只上报结论，这就是后面要聊的端侧 AI 思路。

还有一个容易忽略的判断维度：主控的算力需求。如果你的算法需要几十 MFLOPS 的持续算力，超低功耗 SoC 的 M 核撑不住，强行跑会让动态电流从微安级飙到毫安级，功耗模型整个崩掉。这时候正确的做法是让 BLE SoC 只做通信和调度，算力活交给专门的协处理器，两边用 SPI 或 UART 协作。

2. 把 PHY6270 放进真实需求里：三张表完成选型取舍

绕过一轮选型之后我发现，芯片选型最常见的错误不是"选错了芯片"，而是"用错了评判维度"。大家习惯性地去比主频、比 Flash 容量、比 GPIO 数量，这些参数在官网表格里一目了然，但它们几乎不决定项目成败。真正决定成败的是另外三张表，而且这三张表官方往往不会直接给你，得自己从数据手册的字缝里抠出来。

我通常在项目启动阶段就画好这三张表，把候选芯片填进去。填不满的那一列，往往就是后面要栽跟头的地方。

2.1 功耗表：三个电流数字对应三种真实场景

这张表只看三行，但每一行都要挖到具体测试条件。

第一个数字是地板，它决定了理论续航上限。第二个数字是日常工况，它决定了你的产品在"待机但连着"状态下能撑多久。第三个数字影响的是瞬时压降——这点很多人忽略，如果电池内阻大或者走线细，射频突发瞬间会把供电拉塌，导致复位或者丢包。

这里有个细节值得单拎出来说：是否内置 DCDC 转换器，对功耗表的影响可能是倍数级的。LDO 供电方式下，射频峰值电流会明显高于 DCDC 方式，因为多余的电压都以热的形式浪费了。选型时如果看到"支持 DCDC 模式"，基本可以认为峰值电流能压下来 30% 到 50%。但代价是外围要加电感电容，BOM 成本和板面积要一起算。

注意：数据手册里的休眠电流经常是在特定条件下测的，比如"仅 RTC 运行、RAM 全部掉电、25℃"。你要用的是"RTC + 8KB RAM 保持 + 看门狗开启"，条件一变，数字能翻两三倍。看到手册数字先别高兴，翻到测试条件那一页对照你的实际配置。

2.2 资源表：内存墙决定了你能不能塞进端侧模型

第二张表是关于存储和算力的。这一行我要多写几句，因为现在做电池供电端侧 AI 视觉模块的人越来越多，而 Flash 和 RAM 是这类项目最硬的约束。

BLE SoC 的片上 Flash 常见在 256 KB 到 1 MB 区间，SRAM 在 32 KB 到 256 KB 区间。听起来还行？但你要从里面扣掉协议栈、Bootloader、OTA 分区、文件系统。一颗标称 512 KB Flash 的芯片，协议栈吃 150 KB，OTA 双分区占掉一半，留给你应用逻辑的可能只剩一百多 KB。这个数字对普通应用绰绰有余，但如果你打算塞一个哪怕是小型的神经网络进去，就会立刻感受到什么叫"内存墙"。

所以看资源表的正确姿势是：先把必然开销列出来减掉，再看剩下的余量。协议栈占用、OTA 分区策略（单分区、双分区还是外挂 Flash）、是否有 ROM 化的协议栈可以把 Flash 省下来，这三项先问清楚。特别是 ROM 协议栈这一点，对成本敏感的产品非常关键，能直接把可用的 Flash 空间翻倍。

算力方面，超低功耗 SoC 的 M 核通常跑在几十到一百多 MHz，带 FPU 和 DSP 指令扩展的会好一些。判断标准不是主频多高，而是"跑一次你的算法要花多少毫秒，乘以电流，等于多少微安时的电量"。这个计算后面第三章会详细展开。

2.3 射频与封装表：被严重低估的成本项

第三张表最容易被跳过，但它经常是项目后期最大的变数。

射频这块要看的不是"支持 2.4 GHz"这种废话，而是：发射功率可调范围、接收灵敏度、是否支持内置巴伦、天线接口形式。发射功率可调很重要，因为近距离场景把功率降到 -20 dBm 能显著省电；接收灵敏度决定了在噪声环境下的链路余量，余量不够就得靠重传补，重传就是额外的射频时间。

封装和引脚排布则直接影响射频性能。QFN 封装、带裸露焊盘、射频引脚单独引出、周围有足够的地引脚——这些是好的射频设计的前提。如果封装很小但射频引脚旁边挤着几个高速数字引脚，那布线时会非常痛苦，串扰和辐射都会成问题。

还有一个隐性成本：认证。射频相关的合规测试是要花钱花时间的，芯片本身过没过认证、有没有可复用的参考设计，直接决定你后面是省一个月还是多烧一轮。选型阶段问清楚原厂有没有现成的认证参考板、有没有配套的天线设计文件，这是实打实省钱的操作。

3. 从电池容量反推连接参数：一套可以手算的功耗模型

选型定下来之后，真正决定续航的是连接参数。而连接参数这件事，大多数人是凭感觉设的——"连接间隔设 1 秒吧，应该挺省电的"。凭感觉的结果就是，要么太保守导致响应慢、用户体验差，要么太激进导致续航直接腰斩。其实这套东西完全可以手算，而且只需要初中数学。

我习惯在项目启动时先用纸笔算一遍，把量级定下来，再去实测校准。算出来的值和实测值差在 20% 以内，就说明模型对了，可以放心用于方案评估。

3.1 把平均电流拆成事件电流和休眠电流

核心公式只有一条：

平均电流 = （射频事件电流 × 事件持续时长 + 休眠电流 × 剩余时长）÷ 总周期

拿一个具体例子算。假设连接间隔设为 1 秒，每次连接事件收发总共耗时 2 毫秒，射频期间平均电流 6 mA，其余时间休眠电流 2 µA。

一次周期的电荷消耗是：6 mA × 2 ms = 12 µA·s，加上 0.002 mA × 998 ms ≈ 2 µA·s，合计约 14 µA·s。周期 1000 ms，所以平均电流约14 µA。

再看一块 CR2032 纽扣电池，标称容量约 220 mAh。220 mAh ÷ 0.014 mA ≈ 15700 小时，约1.8 年。这个结果说明什么？说明在 1 秒连接间隔下，射频本身只贡献了不到 15% 的电荷，剩下 85% 是休眠电流的"地板"。你就算把射频优化到零，续航也只能提升 15%。

再把连接间隔改成 100 毫秒对比一下：同样是 2 毫秒事件、6 mA 峰值，平均电流变成 6 mA × 2 ms ÷ 100 ms ≈ 120 µA，加上休眠那点忽略不计，约122 µA。续航掉到 1800 小时，约75 天。

同样是这颗芯片，参数从 1 秒改成 100 毫秒，续航差了将近 9 倍。

这就是为什么我一直说：先算账，再调参。很多人是先写代码，跑不通了再回头改参数，这时候架构已经定型，改动成本极高。

3.2 连接间隔、从机延迟、广播间隔三根杠杆

三个参数里，连接间隔决定事件频率，从机延迟决定你跳过多少事件，广播间隔决定未连接状态下的开销。它们的组合方式决定了整条功耗曲线。

从机延迟（Slave Latency）是最好用的杠杆，因为它允许你在保持"响应及时"感知的前提下大幅降低平均功耗。举个例子：连接间隔 20 毫秒、从机延迟 49，意味着理论上从机可以连续跳过 49 个连接事件不响应，最坏情况下 1 秒内必然响应一次。看起来响应是 1 秒，实际上只要从机有数据要发，随时可以在下一个连接事件上传——延迟只在主机下行时生效。平均电流因此可以降到 1/50，同时又保住了"随时能上报"的能力。

这个特性对传感器类产品简直是量身定做的：上行数据随时发，下行配置慢一点无所谓。

广播间隔则是未连接状态下的唯一开销。一次广播事件在三个广播信道上各发一包（或者更少，取决于配置），总时长通常在 1 到 3 毫秒。广播间隔 1 秒时，平均电流大约在 15 到 30 µA 区间。把间隔拉到 2 秒甚至更长，电流可以再降一半，代价是被发现的速度变慢。电子价签这类产品可以接受 5 秒甚至 10 秒的广播间隔，因为它不需要被主动扫描发现，只需要自己能发出去就行。

三根杠杆的取舍逻辑可以归纳成一句话：响应速度要求高就压缩连接间隔，数据方向以上行为主就加大从机延迟，不需要被快速发现就拉长广播间隔。三者之间不是独立的，动一个要重新算一遍账。

3.3 算得准却跑不住：三个常见的偏差来源

模型算得很漂亮，实测一跑全崩，这种事我遇到过不止一次。总结下来，偏差基本来自三个地方。

第一个是"隐形漏电"。板子上任何一个接错的上拉电阻、任何一个没过反向电流保护的外设、任何一颗静态电流没查的 LDO，都会在休眠时悄悄吃电。一个 10 kΩ 上拉到 3 V 的电阻，如果在休眠时被拉低，就是 300 µA——比整个芯片的休眠电流高一百倍。这类问题的排查方法后面第六章会展开。

第二个是协议栈的"心跳开销"。有些协议栈在连接状态下会周期性地做链路质量检测、加密密钥更新、连接参数更新请求，这些都会产生额外的射频事件。手册里的平均电流值是理想状况，实际协议栈可能有 10% 到 50% 的额外开销。这个只能在实测中观察，用电流波形去数事件。

第三个是电池本身的行为。纽扣电池在低温下内阻急剧上升，脉冲放电时压降明显，标称容量在高脉冲负载下根本放不出来。而且电池有自放电，年自放电率通常在 1% 到 3%。算续航的时候如果只看"容量除以电流"，实际能跑出来的时间通常要打七折到八折。

4. 电源域、时钟与唤醒源：超低功耗设计真正的战场

参数算完了，代码框架搭起来了，接下来才是真正决定成败的地方。我个人的经验是：超低功耗项目里，80% 的功耗优化发生在电源管理、时钟配置和唤醒源梳理这三件事上，剩下 20% 才轮到协议参数。但大多数人的精力分配恰恰是反过来的，全花在调连接参数上。

4.1 电源域划分与漏电猎杀

现代超低功耗 SoC 内部通常划分了多个电源域：常开域（RTC、备份寄存器）、可关断域（CPU、内存、大部分外设）、独立供电域（射频、模拟前端）。你要做的是搞清楚每个域在每种低功耗模式下是开着还是关着，然后确保进低功耗模式前把所有不需要的域都关掉。

这件事说起来简单，做起来要细心。常见的漏点包括：进睡眠前忘了关 ADC 的参考电压、忘了关比较器、忘了把某个 GPIO 从输出高改成输入或者模拟态、忘了关外设时钟但以为关了电源就没事。尤其是 GPIO 状态这一点，一个输出高电平的 GPIO 驱动外部电路，会在睡眠期间持续消耗电流，而且这个电流不走芯片的电流表，你查芯片手册根本查不到。

我的做法是建一张"睡眠前检查清单"，把每个外设、每个 GPIO、每个时钟开关都列进去，写一个统一的enter_low_power()函数，所有状态在函数里显式配置，绝不依赖默认值。这张清单是随着项目推进不断补充的——每次发现新的漏点，就往清单里加一条。项目做到后期，这张清单通常有二三十条。

提示：查漏电最有效的手段不是看代码，是断开式测量。把板子的电源回路串上电流表，然后逐个把外设的供电或者信号线切断，看电流变化。哪一项一断电流就掉一大截，问题就在哪。

4.2 低频时钟的取舍：内部 RC 与外部晶振的账

低功耗模式下必须有低速时钟维持 RTC 和唤醒定时。这里有个经典取舍：用内部 RC 振荡器还是外挂 32.768 kHz 晶振。

内部 RC 的好处是省两个引脚、省一颗料、省 BOM 成本，而且启动快。坏处是精度差，通常在 ±2% 到 ±5% 之间，而且随温度和电压漂移明显。外挂晶振精度可以做到 ±20 ppm 以内，代价是增加成本、占面积，而且起振需要时间。

那到底怎么选？关键看你的唤醒精度要求。举两个场景对比：

• 每 10 秒唤醒一次采样上报：内部 RC 完全够用，累积几秒的偏差对业务没有任何影响，省下来的成本和空间更值。
• 需要精确对齐时间窗口或者做长周期定时（比如每天定时上报）：内部 RC 的偏差一天累积下来可能到十几分钟，这时候必须上外部晶振。

还有一个折中做法，很多芯片支持用射频活动来校准内部 RC——每次射频事件发生时有精确的时间基准，可以反过来校正低速时钟。这个机制如果协议栈支持，是非常划算的，既省了外部晶振的成本，又拿到了不错的精度。选型阶段值得专门问一句。

4.3 唤醒源清单与中断优先级安排

从低功耗模式唤醒的每一个源，都要在清单上写清楚：什么条件触发、唤醒后需要做什么、做完之后怎么回到睡眠。

常见的唤醒源包括：RTC 定时中断、GPIO 外部中断（按键、传感器中断脚）、比较器输出、射频事件、看门狗。这里最容易出问题的是唤醒后处理不完整——比如被按键唤醒了，处理完按键逻辑之后忘了重新配置低功耗模式，结果芯片就一直在运行模式待着，电流从 2 µA 跳到 2 mA，你能从电流曲线上看到一条明显异常的长平台。

中断优先级的安排也有讲究。射频事件的中断通常必须给高优先级，因为蓝牙协议对时序有严格要求，中断被拖太久会导致连接丢失。而采样类的中断可以给低优先级，晚几毫秒无所谓。如果优先级配反了，你会看到很诡异的现象：连接时不时断开，但又找不到原因，其实是一次低优先级长任务把射频中断堵住了。

另外提醒一点，唤醒源不要贪多。我见过为了"灵活性"把所有 GPIO 都配成唤醒源的方案，结果任何一个引脚上的毛刺都能把芯片唤醒，平均电流直接崩掉。唤醒源应该是明确的、经过验证的最小集合。

5. 电池供电的端侧 AI 视觉节点：把 PHY6270 放到系统里看

前面四章讲的都是单颗芯片的事。但真实产品从来不是单颗芯片，而是一套系统。最近"电池供电的端侧 AI 视觉模块"这个概念很热，恰好能拿来说明 PHY6270 这类超低功耗 BLE SoC 在系统里的正确位置。

先说结论：这一类 SoC 通常不做视觉处理，它做的是调度、唤醒决策和结果回传。把图像采集和推理塞进 BLE SoC 里，绝大多数情况下是行不通的，不是不能跑，是跑起来不省电，违背了选它的初衷。

5.1 为什么不做"永远在线"的摄像头

图像传感器是个耗电大户，哪怕是很低分辨率的灰度传感器，连续采集时的电流也在毫安级。更别说采集完还要搬运、还要推理，算力和内存带宽都不够。在纽扣电池或小容量锂电供电的节点上，让摄像头一直开着，续航会直接掉到几小时甚至几十分钟，这跟"超低功耗"四个字完全矛盾。

所以端侧视觉节点的架构必须建立在"事件驱动"上：绝大多数时间摄像头是断电的，只有被事件触发时才上电采集一帧或者几帧。

这个思路听起来简单，但它的工程难度全在触发环节：怎么用最少的功耗判断"现在值得拍一张"。

5.2 分级唤醒：从事件触发到图像回传的完整链路

我一般把这类节点设计成三级唤醒结构。

第一级是超低功耗常驻感知。用 PIR 人体感应、微波雷达、或者简单的光敏/振动传感器，功耗在微安级，全天在线。这一级的任务只有一个：判断"有没有值得关注的事发生"。它不需要知道发生了什么，只需要给一个信号。

第二级是主控上电决策。BLE SoC 从深度睡眠中被唤醒，读取第一级传感器的状态，结合时间、历史记录、简单阈值做初步判断——比如"五分钟内已经拍过三次了，这次跳过"，或者"现在是夜间，灵敏度阈值提高"。这一级完全跑在超低功耗 SoC 上，耗时几毫秒，算力需求极低。

第三级是视觉模块上电采集与推理。只有前两级都通过，才给摄像头和推理协处理器上电。采集一帧，做一次推理，得到结论（有人/没人、有车/没车、数量是多少），然后立刻断电。整个第三级的工作时间要控制在几百毫秒以内，这段时间是功耗峰值，但因为时间短，平均下来仍可接受。

回传环节就交给 BLE SoC 了。这里有个实用技巧：不要在推理结束的第一时间就发起连接，而是把结论缓存起来，等下一个连接事件顺手带上去。这样避免了一次额外的射频唤醒开销。如果结论不紧急，甚至可以等积累几条再一起上报。

5.3 模型、算力与内存的三方匹配

端侧视觉推理要跑起来，模型大小、算力、内存三者必须互相匹配，缺一个都跑不动。

模型这边，量化是必选项不是可选项。一个浮点的轻量分类网络量化到 int8 之后，体积缩到四分之一，推理速度提升两到四倍，精度损失通常在 1% 到 3% 之间，对"有没有人"这种二分类任务完全够用。量化之后再考虑结构化裁剪，把冗余通道砍掉。

算力这边，注意区分"峰值算力"和"持续算力"。手册上标的算力指标通常是在满频满供电下的理论值，实际在低功耗场景下你要降频跑，持续算力可能只有标称的一半。评估时要用实测的推理耗时来算，而不是用标称算力倒推。

内存这边，最容易被忽略的是中间激活值占用的 RAM。很多人算模型大小只看权重，结果权重装得下，中间张量装不下。评估时要按峰值内存来算，而且要给协议栈、DMA 缓冲留出余量。如果片上 RAM 实在不够，可以考虑用外部 SPI PSRAM，但要注意外部内存的访问功耗和速度都会打折。

三者匹配好之后，回到前面第三章的公式算一遍：第三级上电 300 毫秒、平均电流 15 mA，那一次采集事件消耗约 1.25 µA·h；如果一天触发 50 次，就是 62.5 µA·h。对比一块 220 mAh 的电池，这点消耗完全可以忽略。关键就在于"一天触发多少次"和"每次跑多久"这两个数字要压住。

6. 实测电流超标、天线翻车与量产一致性：几个真掉过的坑

前面讲的是方法论，这一章讲的是我实际踩过、也看别人踩过的坑。这些东西在任何一份数据手册和应用笔记里都找不到，只能靠一次次烧板子换回来。

6.1 电流比预期高一个数量级，按这个顺序查

实测休眠电流是 40 µA 而预期是 2 µA，这种情况太常见了。我现在的排查顺序是固定的，从外到内，五分钟内基本能定位。

第一步，断开所有外部电路，只留最小系统供电。如果电流立刻降到预期值，问题在外部电路；如果还是高，问题在芯片配置或者芯片本身。这一步能省掉大量时间，因为外部电路的问题远比芯片配置问题常见。

第二步，逐个上拉/下拉电阻检查。重点是那些在睡眠期间可能被拉成中间电平或者被外部反向驱动的引脚。一个被外部拉低的上拉电阻就是实打实的漏电通道，而且它不体现在任何芯片参数里。检查方法很简单：把所有外部信号线一根根断开，看电流变化。

第三步，逐个外设关闭。写一段测试代码，进睡眠前依次关闭 ADC、比较器、定时器、UART、SPI，每关一个测一次电流。哪一个关掉之后电流掉下来，问题就在哪里。我遇到过 UART 的 RX 引脚悬空导致输入级振荡的情况，把引脚配成上拉之后电流立刻正常。

第四步，查调试接口。SWD 或者 JTAG 接口在调试模式下往往不会真正进入深度睡眠，必须断开调试器再测。这个坑我至少踩过三次：插着调试器测出来 200 µA，拔掉之后再测就是 2 µA。测试方法一定要在文档里写清楚，不然换个人测又会绕回来。

第五步，看芯片的勘误表。有些芯片的某些低功耗模式在特定配置下确实存在额外电流，原厂会出勘误文档和规避方案。项目开始时就该把勘误表读一遍，而不是出问题了才去翻。

6.2 2.4 GHz 天线与地平面：最容易翻车的地方

射频这块我见过太多"电路照着参考设计抄的，但就是距离短"的案例。问题通常不在原理图，在 PCB。

地平面是射频设计的地基。天线的正下方和净空区必须完整铺地，不能走线、不能放器件、不能有分割。很多人为了塞物料，在天线下面放了个电容或者走了一根信号线，结果地平面被破坏，天线效率掉一大截。这个错误的代价是：通信距离从 30 米掉到 5 米，而且很难通过后期调试补救。

匹配网络要根据实物调。参考设计上的 π 型匹配网络（通常是三个元件）给的是起点值，不是终点值。板子做出来之后必须用矢量网络分析仪测回波损耗，在实际装配状态下（包括外壳、电池、人手）调到位。这里有个细节：一定要在最终形态下调天线，裸板和装壳之后的谐振点可能差几十 MHz，裸板调好了装壳就废了。

回流路径要短。射频信号的回流走最短路径回到源，如果地平面被分割，回流路径被迫绕远，就会形成环路辐射，既降低效率又增加干扰。高速数字信号线也要远离天线区域，尤其是时钟线和开关电源的走线。

发射功率不要盲目调到最大。我见过为了"信号好一点"把功率拉到最大的做法，结果功耗上去了，而且近距离时接收端饱和，反而出现丢包。合理的做法是根据实际链路质量动态调整，或者干脆在应用层做自适应。

6.3 从样机到量产：一致性与产测

样机能跑，量产出问题，这是另一类坑。超低功耗产品的量产一致性，主要卡在三个地方。

第一是晶振的频率一致性。低速晶振的频率偏差会直接影响射频时序，偏差过大的批次可能出现连接不稳定。所以晶振的精度等级要选对，而且供应商要稳定。射频用高速晶振的要求更高，通常要 10 ppm 以内，这一项在 BOM 成本里占比不大但重要性极高。

第二是天线的一致性。板厂的工艺波动、外壳装配的公差，都会导致天线的谐振点漂移。量产阶段建议在产线上做一次射频功率或者灵敏度的抽检，用简单的测试夹具测发射功率和接收灵敏度，超差的产品挑出来。这一步能挡掉很多后期返修。

第三是功耗的一致性。休眠电流如果某个批次整体偏高，通常是物料问题（某颗电容的漏电流、某颗芯片的批次差异）或者工艺问题（助焊剂残留导致微短路）。产线上至少要做一次休眠电流的抽测，把异常批次挡住。

还有个经验：产测程序不要用开发板的代码。开发板为了调试方便往往开了很多不必要的功能和日志，直接搬到产测上会把功耗和时序都带偏。产测固件应该是精简的、只包含必要测试项的独立版本，而且要能自动判断通过与否，减少人工判断的误差。

做到这一步，一颗超低功耗 BLE SoC 从选型、功耗建模、参数设计到量产，整条链路才算走通。回过头看，真正难的地方从来不是某个具体的知识点，而是把功耗当成一条贯穿始终的主线去对待——从第一张电流表读数开始，到最后一台产品出厂，中间每一个决策都要问一句：这个选择，会让我的平均电流变大还是变小。