企业官网建设流程全解析

做卫星发射器模块有一段时间了，这半年走完了一轮从需求梳理到样机量产验证的过程，中间踩了不少坑，也沉淀出一些真正有用的经验。最近正好同事问起：“为什么一颗BLE SoC能跑卫星发射器的控制逻辑？”我觉得可以把整套方案摊开来讲一讲，顺便把手上的实测数据、代码结构、调试心得一并分享一下。这个项目本质上是用Nordic的BLE SoC（我们选的是nRF52840）作为卫星发射器模块的主控，把参数配置、状态监控、日志回传、固件升级这些原本需要有线接口做的事情全部搬到蓝牙无线上来。如果你正在做卫星通信载荷、地面站配套设备、便携式发射器，或者只是对BLE SoC在复杂射频系统中的用法感兴趣，这篇文章应该能给你不少可复用的思路。

可以这么说，选型时很多人一听“卫星发射器”就觉得必须上高端FPGA加Linux SoC，实际上模块内部不同层级有不同任务，配置管理类工作完全可以用一颗低功耗蓝牙SoC来处理，而且效果好得出乎意料。不过这里必须先说清楚：卫星发射器工作在S频段或更高频段，BLE的2.4GHz无线链路并不会直接参与星地通信，这颗Nordic SoC的角色是“控制核心 + 无线维护通道”，它负责调度发射链路、管理配置参数、采集遥测数据，同时通过BLE与手机或电脑完成近场维护。整体架构里，BLE SoC和射频发射链路之间通常用SPI或UART连接，控制PLL频率字、功放增益、滤波通道，读回功放温度、供电电流、驻波比等信息。

1. 项目整体设计与芯片选型思路

1.1 卫星发射器模块里，一颗BLE SoC到底在干嘛

先别急着把“BLE SoC”和“卫星发射器”这两件事对立起来，拆开看模块内部的工作就很清晰了。一个典型的小型卫星发射器模块，主要由发射链路和控制电路组成，发射链路负责把基带信号上变频到射频、放大到指定功率，控制电路负责给发射链路供电、设置工作频率、切换增益挡位、监测功放状态。在早期设计中，控制电路一般是一颗MCU加片外FLASH，所有配置通过UART或JTAG接口完成，维护人员需要开盖接线才能改参数，这在实验室打样阶段还勉强能用，一旦到了整星集成或者外场测试阶段就非常痛苦。

把Nordic BLE SoC放进来之后，模块就多了一条无线维护通道。手机上的配置App通过BLE连接模块，可以一次性读取当前工作频率、输出功率、供电电压、功放温度，也可以下发新的频点参数和功率校准表，甚至可以直接把新的固件包通过BLE刷进去，整个过程不需要打开屏蔽盒，不需要找USB线，更不需要在装配好的卫星结构件里翻Debug接口。这么做还有一个附带好处，整星测试阶段可以通过BLE在近距离完成各项发射参数确认，降低反复装卸的风险。

需要注意，这里BLE的数据通道并不是星地遥测的主链路，遥测数据最终还是要通过发射器本身的射频链路发出去，BLE只是近场维护口。但对于工程师来说，这条维护通道的存在直接改变了调试方式，以前调频率要用频谱仪对着电路板找焊点，现在坐在电脑前点几下就完成了。

1.2 为什么选Nordic而不是ESP32、STM32加蓝牙模块

选型阶段我对比过几类方案，包括ESP32系列、STM32外挂BLE模块、TI的CC2640系列，以及Nordic的nRF52系列。每一类都有明显的适用场景，但放到“卫星发射器模块主控”这个具体位置，有几个指标基本是硬性的，包括协议栈长期稳定性、极端环境下的启动可靠性、低功耗休眠能力、外设接口的充足程度、以及SDK和调试工具链的成熟度。

从实际使用感受来说，Nordic的SoftDevice协议栈在BLE连接稳定性上是第一梯队。我们做产品测试时跑过7×24小时的持续连接，手机端反复开关蓝牙、进出信号覆盖区，协议栈都能自己恢复，极少出现需要整体复位的情况。ESP32我们早期也试过，Wi-Fi与BLE共存场景下性能不错，但卫星发射器旁边的射频环境比较极端，射频干扰会把BLE的丢包率拉高，而Nordic在2.4G抗干扰和协议栈错误处理上更符合我们的要求。

STM32加外挂BLE模块的方案在项目选型时其实也有人提，好处是STM32的工程师很熟，坏处是多了AT指令这一层，很多底层状态拿不到，做DFU和低功耗管理会很吃力。如果你只需要简单的串口透传，那个方案没问题，但我们需要在协议层做业务解析、批处理参数校验、甚至配合上位机做分片重传，用SoC单芯片方案更顺。

还有一个细节很多人忽略：Nordic的nRF5 SDK和nRF Connect系列工具做得非常顺手，尤其是SoftDevice加SES（Segger Embedded Studio）的组合，编译、下载、RTT日志一条龙，比很多芯片厂的开发体验好太多。对项目周期短、人手少的团队来说，工具链体验会直接影响交付效率。

1.3 硬件架构与接口分配

我们的模块硬件拓扑大概是这样的：nRF52840作为主控，通过UART与发射链路中的频率综合器/功放控制芯片通信，通过I2C挂在温度传感器和电流监测芯片，通过ADC采集若干电压点，GPIO控制各路电源开关和功放使能。电源侧，卫星平台的母线电压通常是5V或更高，一路通过高效率DCDC降到3.3V给主控和低速外设供电，一路经LDO给射频链路模拟部分供电，保证纹波尽可能低。

引脚分配上，UART是核心通道，建议把RX/TX引到带流控的接口上，因为发射链路控制芯片可能不支持很复杂的协议交互，流控能避免数据丢失。I2C上建议挂一路备用地址拉高/拉低的选择电阻，方便同一条总线上扩展多个传感器。ADC通道至少留三路：主电源电压、功放供电电流采样、以及一个预留的模拟量输入。GPIO里要保留至少一个可触发中断的引脚给外部唤醒信号，比如定时器唤醒、外部指令唤醒等。

时钟设计上必须用外部32MHz晶振和32.768kHz低速晶振，nRF52840虽然支持内部振荡器，但BLE协议对时钟精度有要求，内部RC在温度变化时频偏会超出BLE规范。卫星发射器的工作温度范围通常很宽，这里不建议省晶振的钱。

供电和地的处理值得多说一下。发射链路里PA开关瞬间会拉出很大的电流，如果PCB布局不佳，会在电源网络上激起明显纹波，而这个纹波会直接影响nRF52840的射频性能，导致BLE丢包甚至连接断开。我们在实际layout时就吃过这个亏，后来把BLE的射频地、数字地、模拟地在底层做了单点分割，PA电源走短粗星型走线，并用π型滤波隔离，问题才解决。热搜词里那条“rf soc器件gen3 adc电源纹波”其实说的也是类似问题，ADC和射频电路共享电源时，纹波会同时影响采样精确度和射频指标，必须从源头控制。

2. BLE通信与协议栈核心细节

2.1 连接参数怎么配才能又稳又省电

BLE连接参数是整个通信体验的根基，很多“连上就断”“信号明明很好但收发不畅”的问题，根源都在参数配得不对。BLE连接参数主要包含连接间隔、从机延迟、监督超时三个核心值，它们之间互相约束。连接间隔决定了一个连接事件多久发生一次，从机延迟允许从机跳过若干个连接事件而不必每次醒来，监督超时则决定了连接丢失多长时间后系统判定链路断开。

这里给出一组我实测比较稳的参数：连接间隔30ms，从机延迟9，监督超时4秒。用这组参数时，从机大约每300ms才需要真正收发一次数据，平均电流可以压到很低，同时4秒的监督超时又给链路足够的容错时间，短暂的环境遮挡不会立刻触发断连。吞吐量确实不高，但配置维护场景本身不需要大量灌数据，稳定性优先。

如果你需要短时间传个大文件，比如批量日志或固件包，就需要动态调整连接参数。BLE协议栈允许应用在连接建立后发起连接参数更新请求，把连接间隔临时收紧到15ms、从机延迟设为0，传完再改回来。这样兼顾了平时低功耗和紧急高吞吐两个需求。需要注意，连接参数更新请求最终是否生效由主机决定，iOS和Android的策略不完全一样，Android一般会采纳，iOS有部分版本会有过滤逻辑，所以调用后务必检查实际参数，不要假设一定会生效。

数据传输速率方面，理论吞吐和实际吞吐差距很大。nRF52840在BLE 5.0、2M PHY、最大连接事件长度条件下能跑到1.4Mbps左右，但那是实验室极限。实际做DFU时，经过分包、协议头、CRC、ACK等待，加上手机侧的调度开销，能稳定跑50KB/s已经算不错了。所以设计上层协议时，一定要留分片和续传机制，不要假设底层能一次把大文件扛过去。

2.2 GATT服务设计与MTU大小选择

GATT层是BLE应用逻辑的核心。我们为这个卫星发射器模块设计了三组服务：配置服务、遥测服务、日志服务。配置服务使用Write或Write No Response接收指令，用Read或Indicate返回执行结果；遥测服务主要用Notify主动上抛状态数据；日志服务是独立的，专门用来接收调试日志和固件升级过程中的进度事件。每组服务都有独立的UUID，建议基于自定义128-bit UUID，不要用16-bit的公开服务UUID，避免和系统服务冲突。

MTU大小直接影响单包数据承载量。BLE 4.0时代MTU是23字节，扣除ATT头用户数据只有20字节，传输效率很低。nRF52840支持BLE 5.0，可以把MTU协商到247字节，单包有效载荷最高244字节，配合Notify一次能灌很多数据。实现时，从机侧要做两件事：在初始化时声明支持的最大MTU，并在连接建立后处理MTU交换请求。很多新手只设置了ATT_MTU，却没有在协议栈初始化时开放相关配置项，结果协商后依然只有23字节。

还要注意Notification和Indication的区别，前者不需要接收端确认，丢包不重传；后者每个包都需要ACK，可靠性更高但吞吐会降下来。配置服务和日志服务建议用Indication，关键指令不允许丢；遥测服务用Notification就好，状态数据本身是周期性的，丢一帧下一帧会补上。

2.3 从机角色之外，还要不要做主从一体

多数卫星发射器模块的BLE角色是从机，也就是Peripheral，手机或电脑作为主机来连它。但在实际系统中，模块有时还要主动去连周边传感器节点，比如发射器内部的一个独立环境监测子板、或者工装上的夹具传感器。这时就需要nRF52840工作在主从一体模式，既能被手机连接，也能作为主机去连接其他从机。

主从一体是很多人踩坑的地方。在SoftDevice架构下，可用连接数量受内存和协议栈配置限制，每增加一个连接都会占用RAM和协议栈资源。如果你同时跑一个连接当从机、一个连接当主机，需要合理配置协议栈的连接数参数，并给协议栈预留足够的堆空间。我们在项目里用nRF52840做过同时维持两个连接（一个手机、一个传感器）的测试，前提是合理裁剪协议栈特性，比如只保留需要的GATT服务和底层协议特性，才能稳定运行。

如果你的系统需要更多连接或更复杂的并发逻辑，建议考虑nRF5340或者直接用Zephyr的蓝牙协议栈，比SoftDevice的多连接配置更灵活。不过对绝大多数发射器模块来说，nRF52840的主从一体能力已经足够用了。

3. 从零搭建工程：快速跑通BLE广播

3.1 SDK工程结构搭建与sdk_config裁剪

这里以nRF5 SDK 17.1.0 + SoftDevice S140为例，把工程搭建的流程说一遍。先从Nordic官网下载SDK，目录结构里examples/ble_peripheral是各种外设例程，找个最接近的模板复制出来改。我们最初就是基于ble_app_uart这个例程开始改的，因为它已经有UART+BLE双向透传的基础框架，把串口透传部分替换成我们自己的协议解析就是。

sdk_config.h是整个工程的开关总闸，里面定义了所有模块的使能宏。很多人拿到例程不裁剪，跑个HelloWorld就完事，等代码越来越多就发现RAM不够、Flash不够、功耗偏高。建议按以下原则来裁剪：用不到的外设模块全部注释掉，比如没用到TWI就把TWI_ENABLED关掉；BLE服务只看需要的，不需要的示例服务关闭；日志输出在release版本关掉，否则UART会持续产生中断，功耗下不来。每关一个模块就编译一次确认没引出新错误，这样你能很清楚地知道配置项对应哪些代码段。

工程里还要注意Event Dispatch机制。SoftDevice回调是在协议栈事件上下文里执行的，不建议在这里做耗时操作，比如Flash擦写、协议解析、长字符串格式化，否则会阻塞BLE协议栈，直接导致丢包或断连。正确做法是把事件入队，在主循环或RTOS任务里处理。这也是从例程代码到产品级代码必须迈过的一步。

3.2 广播配置与连接事件回调的实现细节

广播配置是BLE设备的第一步。我们用的是可连接广播，广播包内容包含设备名、服务UUID、以及自定义的标志字段。广播间隔设为100ms，既不至于太耗电，又能让手机快速搜到。实际测试中，100ms广播间隔下，手机从打开App到发现设备一般在1到3秒内。

广播数据里建议放一个短设备标识，比如固件版本号或模块编号，这样在产线批量测试时，可以用手机快速识别出哪台设备对应当前被测对象。

核心代码大致如下：

static void ble_adv_start(void) { uint32_t err_code; ble_gap_adv_params_t adv_params; ble_gap_adv_data_t adv_data; uint8_t adv_handle = BLE_GAP_ADV_SET_HANDLE_NOT_SET; uint8_t adv_buf[BLE_GAP_ADV_SET_DATA_SIZE_MAX]; uint8_t scan_buf[BLE_GAP_ADV_SET_DATA_SIZE_MAX]; memset(&adv_params, 0, sizeof(adv_params)); adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED; adv_params.interval = MSEC_TO_UNITS(100, UNIT_0_625_MS); adv_params.duration = BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED; ble_gap_adv_data_t adv_data = {0}; adv_data.adv_data.p_data = adv_buf; adv_data.adv_data.len = build_adv_data(adv_buf, sizeof(adv_buf)); adv_data.scan_rsp_data.p_data = scan_buf; adv_data.scan_rsp_data.len = build_scan_rsp_data(scan_buf, sizeof(scan_buf)); err_code = sd_ble_gap_adv_set_configure(&adv_handle, &adv_data, &adv_params); APP_ERROR_CHECK(err_code); err_code = sd_ble_gap_adv_start(adv_handle, APP_BLE_CONN_CFG_TAG); APP_ERROR_CHECK(err_code); }

连接事件的回调处理是BLE应用的关键，所有业务逻辑都发生在BLE_GAP_EVT_CONNECTED和BLE_GAP_EVT_DISCONNECTED之间，建议维护一个工作状态机，至少包括空闲、广播中、已连接、待配置、固件升级中这几个状态。断连后要自动重启广播，并做一次彻底的外设状态复位，避免上一次连接残留的状态影响下一次连接。

3.3 业务指令协议设计：别把BLE当串口用

很多工程师做BLE业务时直接把收发缓冲区的数据当成串口数据流处理，这在链路质量好的时候问题不大，一旦出现丢包、乱序、重复包就非常难看。我们在模块设计里定义了一套带帧头、长度、CRC、序列号的最小帧协议，保证每条指令的完整性。

帧格式为：帧头(2字节，固定0xA55A) + 长度(1字节) + 指令码(1字节) + 序列号(1字节) + 数据(N字节) + CRC16(2字节)。序列号用于去重和响应匹配，接收方收到指令后立即回一个ACK帧，携带相同序列号。这样即使底层BLE发生丢包和重传，上层协议也不会乱。

后来把DFU、配置下发、日志回传都建在这套最小帧之上，扩展性非常好。如果你现在还在做协议层设计，强烈建议把序列号和CRC作为一个基本功，不要因为省几个字节去掉它。

3.4 DFU固件升级：小程序、安卓、C#上位机的实操记录

DFU是BLE SoC产品最见功力的地方，比普通业务开发难的不是一点半点。Nordic的Secure DFU方案把固件拆成三块：Bootloader、SoftDevice、Application。OTA时可以通过合并固件包一次写入，也可以分开升级。其原理是利用Bootloader在启动阶段检查DFU入口标志，如果发现升级请求，就进入DFU模式接收新固件，写入外部Flash或内部Flash合适区域，完成后跳转到Application。

微信小程序做DFU是我们实际项目里最常用的模式，因为现场维护人员不用装专用App，扫码打开小程序就能给模块升级。小程序蓝牙API有严格的包长限制，默认一次写20字节，需要在写入前主动协商MTU，但即使协商成功，部分小程序运行环境仍会限制写入分片。我们的做法是DFU上层每包244字节，但这244字节在小程序侧再分包为20字节一帧，连续写入后再等板端ACK。这个问题在折腾了整整两天后才理清楚，如果你也遇到“小程序DFU写到一半失败”，先检查是不是每次都写了超过平台限制的长度。

Android端的实现相对简单，官方有nRF Toolbox的源码可以参考，核心逻辑是扫描到设备后连接DFU Service（UUID是0000FE59-0000-1000-8000-00805F9B34FB），然后通过Write和Notify交互。但要小心Android机型对BLE的兼容性差异，个别机型在连接状态下与DFU Service交互时会有异常，需要在Application层增加超时重连。

桌面端我也用C#实现过一个上位机，用的是32feet.NET库做蓝牙管理，配合Windows自带的BLE API或者直接走nRF的USB Dongle，效果很不错，适合产线批量升级。C#侧要注意线程同步，BLE回调事件默认在非UI线程触发，不能直接在回调里刷新界面控件。所有UI更新统一用Dispatcher.Invoke切回主线程。

还有一个所有DFU都会遇到的坑：升级过程中手机锁屏、后台杀掉App、或者BLE连接断掉，都会导致升级中断。稳妥的做法是在Bootloader里实现断点续传逻辑，记录当前写入的偏移量，再次进入DFU时从上次位置继续。Nordic的Secure DFU协议本身支持分段写入，强烈建议在上层把“断点续传”做成一个显式功能，否则卫星模块一旦升到一半离电，返厂返修的成本会非常高。

4. 功耗、天线与射频实测调优

4.1 低功耗调优的实测记录

如果模块是电池供电，功耗就是命根子。nRF52840的休眠性能很强，System ON模式下配合RTC唤醒，典型电流能做到2.5微安，但这个数字不是默认就有，需要把外设全部关干净、GPIO全部配置为无上拉无下拉或固定电平，并且确保没有外部分压电阻在漏电。

我们实测过一组数据，在广播间隔100ms、Tx Power 0dBm时，广播平均电流在40微安左右；连接状态、连接间隔30ms、从机延迟9时，平均电流在0.6毫安左右；持续UART通信时电流会跳到5毫安以上。所以如果发射器模块里有遥测采集任务，需要设计合理的占空比采集策略，不要一直开着传感器。

低功耗调优有几个容易忽略的点：一是UART空闲时不要一直开着时钟，二是I2C外设不用时一定要释放总线，三是所有GPIO都不能悬空，悬空的输入引脚会在上下电过程中反复震荡，白白增加电流。我们用功耗分析仪逐项排查时，发现一个看似无关紧要的LED指示灯限流电阻选小了，导致待机电流多了近200微安，这类低级错误要特别注意。

4.2 天线设计与射频匹配的现场经验

发射器模块的天线选择取决于空间和增益需求。如果空间允许，外接SMA接口加鞭状天线或者贴片陶瓷天线是好选择，调试方便，性能可预测；如果做在PCB上，需要仔细设计净空区和匹配网络。

这里必须提醒一句：不要直接抄Nordic参考设计的PCB天线，参考设计只是保证“能工作”，不是保证“在你这块板上性能最好”。天线周围的地、铺铜空隙、外壳材料、安装位置都会影响谐振频率。我们实际做了一块板，天线净空区旁边恰好有一大片铺铜，结果谐振频点偏移了将近100MHz，信号强度掉了10dB以上，后来把天线区域的地挖空、调整匹配电容才恢复。

如果有矢量网络分析仪，建议在调匹配网络时直接看S11参数，目标是在2.45GHz中心频率附近做到-10dB以下。如果没有VNA，至少要在实际环境里通过手机RSSI和通信距离来判断天线性能是否达标。我们实测下来，nRF52840在0dBm发射功率下，开阔地手机连接距离能到80米以上，隔一堵墙大概20米，这基本可以判断天线工作正常。

4.3 射频干扰与电源纹波之战

卫星发射器模块的难点在于，它自身就是一个强射频源。功放工作时，发射链路的泄漏信号和开关噪声会对BLE的2.4GHz接收灵敏度造成很大冲击。我们遇到过非常典型的现象：BLE调试正常，一打开发射链路，手机马上就断开连接。用频谱仪一看，2.4GHz频段上多了杂散信号，正是功放的谐波泄漏。

对策分成三个层面。第一是物理隔离，BLE天线和发射天线尽量分置两侧，中间用地墙和屏蔽罩隔开；第二是电源隔离，BLE射频电源用LDO单独供电，并在PA电源入口加磁珠和π型滤波；第三是时序分时，发射链路只在数据上行的时隙打开发射，其他时间强制休眠，用软件在发射和BLE通信之间做仲裁。手机连接断开问题最终是靠这三个方案叠加解决的，单做哪一项都不够。

电源纹波的问题再单独强调一下。nRF52840内部有DCDC和LDO两种供电模式，启动时默认走DCDC还是LDO由硬件配置决定，DCDC效率高但纹波稍大，LDO纹波小但效率低。在卫星发射器这种射频环境复杂的应用里，BLE射频部分建议直接通过片内LDO，或外部加一级低噪声LDO，优先保证射频性能而不是省那点功耗。热搜词里“rf soc器件gen3 adc电源纹波”说的就是这个方向，尤其当ADC和射频共用电源时，纹波会令ADC采样精度下降，也会拉低射频指标。

5. 常见问题与排查技巧实录

5.1 手机搜不到设备、连上就断，可能是这几件事没做对

搜不到设备时，第一步不要急着改代码，先用nRF Connect这个工具扫描一下，看设备是不是在广播。如果nRF Connect能看到而自己的App看不到，问题在上层过滤逻辑；如果nRF Connect也看不到，问题在广播配置或射频硬件。广播配置里最容易出问题的标志位是广播类型和过滤策略，改成无过滤可扫描可连接类型通常能解决一大部分“搜不到”的问题。

连上就断，最典型的两个原因：一是连接参数不被主设备接受，二是从机在回调里做了耗时操作导致协议栈超时。前者通过打印实际连接事件里的参数确认，后者检查定时器、Flash写入、协议解析等是否有阻塞调用。

5.2 传输吞吐上不去，最大卡点不一定是天线

很多工程师测吞吐时发现实际速率远低于理论值，第一反应是天线路由问题，其实在近场通信时先查软件参数更高效。MTU没有协商成功是最常见的原因，用nRF Connect或日志确认ATT_MTU是否到了247。连接间隔太长和从机延迟太大会让单连接事件里发不了几个包，传输前要临时收起这些参数。

还有一点经常被忽略：Nordic SDK在Notify发送时，如果缓存区满了或者上一条还没发完，会返回NRF_ERROR_RESOURCES或NRF_ERROR_DATA_SIZE。代码里遇到这个错误最忌讳直接丢弃数据，正确做法是等待BLE_GATTS_EVT_HVN_TX_COMPLETE事件之后继续下一包，或者上层做流控。

5.3 小程序DFU莫名其妙失败，先看写入时序

小程序DFU失败的原因五花八门，但归纳下来绝大多数是这三个：写入长度超过平台限制、写入间隔太短导致板端缓冲区溢出、连接被系统挂起导致超时断开。排查顺序建议先看板端串口日志，确认收到多少包、在哪包之后没有ACK。如果是写太快，把每包写入间隔从5ms调整到20ms，很多问题能自愈。

另外，微信小程序的BLE写入有一个容易被坑的机制：多个writePromise并发时，系统会把数据打乱或者直接丢弃。正确的写法是严格串行，等上一次write成功回调后再写下一包，必须用队列串起来，不能靠循环内无条件await。

5.4 睡眠功耗高得离谱，逐个外设断掉排查

功耗异常时不要只看SoC的睡眠电流，要把整个模块纳入测量范围。nRF52840本身可以睡到几微安，但外围传感器、LDO、电平转换芯片、LED限流电阻都可能成为漏电源。排查步骤是：先用功耗分析仪测整板电流，然后逐个关闭外设电源、逐个去使能GPIO、把每个外设芯片的电源引脚与主供电断开，对比每次操作后的电流变化。这个方法虽然笨，但极其有效。

另一个隐藏的漏电源是IO口通过外设芯片反向馈电。比如MCU的某个IO在上电时默认输出高电平，而这个IO又接到了外部芯片的输出端，两边电平冲突会形成持续灌电流，不仅影响功耗，严重时还可能损伤IO。设计初期就给所有外部接口加上默认状态管理，确保复位期间外部器件不会干扰SoC。

这个项目搞到现在，我觉得最有价值的不是跑通了BLE通信，也不是实现了DFU，而是把“低功耗BLE SoC在强射频环境下的可靠性”这件事摸透了。卫星发射器模块这种设备，使用场景往往极端、维护窗口短、出问题代价大，所以控制链路的稳定性就是整个产品的生命线。后续如果再迭代，我打算往nRF5340方向走，把Zephyr用起来，利用双核架构把射频控制任务和BLE协议栈彻底隔离，多线程调度也会比现在的前后台更从容。最后再分享一个小技巧：板子上留一个状态LED，用不同闪烁模式表示广播中、已连接、协议错误、DFU进行中，现场排查问题时你会感谢这个设计。