简介面向低功耗蓝牙开发者的ST BlueNRG355MC芯片例程包内置BlueNRG-LP系列系统级芯片的完整开发套件与示例工程覆盖初始化配置、蓝牙协议栈、连接管理、GATT数据传输、低功耗模式及事件驱动开发等关键环节适用于物联网终端、可穿戴设备及智能家居产品的工程师快速上手。压缩包共两千个文件以C语言与头文件源码、工程配置文件、链接脚本、镜像文件以及说明文档为主并包含完整构建工具链整体大小约二百六十四MB目录结构清晰便于按模块查阅。已有三百四十二人学习下载。开发者通过研读例程可掌握芯片寄存器配置、HCI命令交互、自定义GATT服务创建以及待机、休眠与深度睡眠等功耗优化技巧结合丰富示例代码与构建脚本能显著缩短蓝牙产品的开发调试周期。 手上有块BLUENRG355MC的开发板折腾了大概两周把ST官方的蓝牙芯片例程从下载、编译到跑通自定义业务整个捋了一遍。这芯片是意法半导体BLE产品线里比较新的一个双核Cortex-M0支持蓝牙5.4关键是功耗数据确实能打。但说句实在话ST给的东西虽然全例程分散在不同包里第一次接触的人很容易在工程结构和编译链路上卡住。这篇就把我实际跑通的过程、踩过的坑、还有几个容易被文档带偏的细节一次性说清楚给准备上手BLUENRG355MC的人省点时间。1. 上手前的准备拿到芯片先别急着写代码1.1 需要准备的软硬件环境BLUENRG355MC的开发调试跟普通MCU不太一样它不是用ST-Link直接连SWD就能随便玩的官方推荐的方式是板载ST-LinkNucleo板配合ST BLE Toolbox或者ST BLE Sensor这类上位机来跑例程。我这里用的是STEVAL-IDB011V1评估板板上带了ST-Link/V2-1也预留了SWD接口方便用J-Link做底层调试。软件这边最重要的不是IDE而是ST的BLE协议栈SDK。很多人以为装个STM32CubeIDE就能直接干实际不行你得单独去ST官网下载BlueNRG-LPSDK注意不是BlueNRG-1/2那个旧SDK解压后里面才带BLUENRG355MC的驱动库、协议栈库、以及各个外设和BLE应用的例程工程。环境清单整理一下组件说明STM32CubeIDE官方IDE1.10以上版本支持BLE工程导入BlueNRG-LP SDK从ST官网下载当前版本一般到2.x评估板STEVAL-IDB011V1或自定义硬件Android/iOS手机用于装ST BLE Toolbox做无线调试USB线数据线别用只充电的那种我一开始图省事想直接用旧SDK结果编译直接报找不到BLUENRG355MC的器件头文件后来才搞清楚这个芯片走的是BlueNRG-LP系列SDK千万别下错了。1.2 例程包的结构和选型思路SDK解压出来后目录结构大概是这样BlueNRG-LP_SDK/ ├── Projects/ ├── Drivers/ ├── Middlewares/ ├── Utilities/ └── Documentation/Projects下按开发板和场景分成很多子目录比如BLE_Beacon、BLE_Chat、BLE_SensorDemo、BLE_Throughput等等。我建议第一次接触BLUENRG355MC的人不要直接看复杂工程先跑通BLE_Chat或者BLE_SensorDemo这两个例程短小精悍能覆盖广播、扫描、连接、收发数据这四个基本流程。选例程有个原则如果你的目标应用是低功耗传感器节点直接看SensorDemo如果是要做透传或者数据交互看BLE_Chat如果你只是想知道芯片射频性能直接跑Throughput例程。不同例程的协议栈配置差异很大不要试图在一个例程上改出所有功能这是很多新人掉坑的开始。另外需要注意BLUENRG355MC的SDK里虽然有Keil和IAR的工程文件但我用下来STM32CubeIDE的兼容性最好工程导入后基本零配置就能编译。Keil的工程还依赖ARMCC版本版本不对会报一堆垃圾错误。2. 例程核心机制拆解从底层驱动到应用层2.1 BLE协议栈与双核架构的关系BLUENRG355MC内部其实是两个Cortex-M0核一个跑应用代码另一个跑BLE协议栈。这个双核设计对使用者来说几乎透明因为ST把协议栈封装成了库你只需要在应用核里调用API即可根本不用关心射频链路层怎么调度。例程代码里常见这样的初始化/* 初始化协议栈 */ BLE_Init(NULL); /* 设置BLE事件回调 */ BLE_RegisterCallback(BLE_Event_Callbacks);这两行就是整个BLE应用的地基。BLE_Init做的事情是把协议栈核拉起来加载配置参数。BLE_RegisterCallback则是注册事件处理函数后续所有连接、断开、数据接收都会通过回调函数通知应用层。这里有个容易忽略的点BLUENRG355MC的协议栈API和老的BlueNRG-1/2不完全兼容函数名和参数结构都变了。比如老SDK里的aci_gap_set_discoverable()在新SDK里改成了BLE_SetDiscoverable()参数从位掩码变成了结构体指针。如果你搜网上的老帖子抄代码很可能连编译都过不了。所以看例程的时候一定要注意SDK版本。2.2 广播、扫描、连接与数据收发的例程路径我拿BLE_Chat例程举例这个例程完整走了一遍BLE通信的核心流程而且代码量不大非常适合读源码。广播部分核心代码在Chat_Cmd_Start或者初始化函数里大致的调用顺序是BLE_Gap_SetAdvertisingParameters(adv_params); BLE_Gap_SetAdvertisingData(adv_data); BLE_Gap_StartAdvertising();adv_params里要重点关注广播间隔和广播类型。BLE_Chat例程默认是可连接广播广播间隔为100ms这个参数影响功耗和发现速度。如果做低功耗产品广播间隔一般建议200ms以上如果做需要快速配网的设备100ms或更短。扫描部分在手机端其实不用你操心ST BLE Toolbox已经帮你写好了。但如果你想做设备端扫描套路就是BLE_Gap_StartDiscovery(SCAN_INTERVAL, SCAN_WINDOW);然后等待GAP_DISCOVERY_STATE事件回调遍历扫描结果取出广播数据判断是不是目标设备。连接建立后数据收发走的是GATT协议。BLE_Chat例程中定义了一个自定义Service服务UUID是0xFEED特征值UUID是0xF0E1每个例程可能不同。你要做的就是在事件回调里处理写入请求case BLE_GATT_EVENT_WRITE_REQUEST: /* 提取写入数据并回显 */ BLE_Gatt_WriteResponse(conn_handle, att_handle, val); break;这就是一收一发的基础逻辑。BLUENRG355MC的协议栈把底层的分帧、重传、确认都处理好了你只需要面对这些事件即可。2.3 例程里隐藏的功耗控制思路BLE芯片选型时大家最关心的就是功耗。BLUENRG355MC有两种低功耗模式Sleep Mode和Standby Mode。例程里通常用BLE_SetSleepMode()配置配合HAL_GPIO的唤醒引脚实现超低功耗。我看BLUENRG355MC的手册它的Sleep Mode电流号称能做到1uA以下但前提条件是关闭不需要的外设时钟配置好GPIO上下拉状态避免浮空损耗协议栈进入Sleep状态并设置唤醒源例程里面有现成的配置代码但很多人直接跑例程测出来电流很大其实是因为例程默认关掉了低功耗优化方便调试。你要真做产品必须打开BLE_SleepMode_Enter()或者类似接口并且把调试打印串口的时钟在休眠前关掉。这一块如果不会调建议先拿例程里的功耗测试工程去测一遍基线再改自己的应用。盲调功耗会非常折磨人。3. 实操过程编译、烧录到跑通第一个BLE例程3.1 工程导入与编译的详细步骤我用STM32CubeIDE 1.10.1 BlueNRG-LP SDK 2.1.0来操作记一下完整过程打开STM32CubeIDE菜单 File - Import - Existing Projects into Workspace选中SDK下的BLE_Chat工程目录。导入后工程会自动识别芯片型号BLUENRG355MC如果没有自动识别在工程属性里手动选择。编译前要确保SDK的头文件路径已经加好。一般导入后会自动带上但如果报找不到blueNRG1_hal.h之类的就需要手动添加Drivers和Middlewares目录。点击Build第一次编译会比较久因为要把协议栈库链接进去大概一两分钟正常。编译成功后工程目录下会生成.elf和.bin文件。烧录方式有两种我推荐先用板载ST-Link在线烧录。STM32CubeIDE里直接点Run按钮就行它会自动调用ST-Link烧录。这里有个很常见的报错Could not verify ST device!。遇到这个多半是ST-Link的驱动版本太老或者板子上的ST-Link固件需要升级。解决办法是打开STM32CubeProgrammer点击固件升级按钮更新ST-Link固件。注意升级前拔掉所有其他USB设备避免干扰。3.2 用手机App验证掉广播和连接烧录完例程开发板会处于广播状态。打开手机上的ST BLE Toolbox扫描一下就能看到名为BlueNRG-Chat或者类似的设备具体看例程里的CFG_DEVICE_NAME配置。连接流程如下在App主界面下拉刷新扫描列表。找到你的设备点击Connect。连接成功后进入GATT页面能看到设备的所有Service列表。找到UUID为0xFEED的Service点进去在0xF0E1特征值上点击写入发送一个字符串。如果一切正常开发板的串口会打印出你发送的数据或者App端也能看到回显。到这里整个例程就算跑通了。调试中有个技巧在例程源码里找到APP_UPDATE_CFG或者BLE_DEBUG这类宏打开串口打印功能这样可以在PC端通过串口工具看到协议栈内部事件对排查问题事半功倍。3.3 修改广播名称和业务UUID例程跑通后建议做两件事改设备名、改Service UUID。这两步做完基本就告别只会跑例程的阶段了。改设备名很简单在代码里搜索CFG_DEVICE_NAME或者ADV_DATA相关的宏定义。比如#define CFG_DEVICE_NAME MySensor改成你自己的名字即可。注意广播名称的长度有限制BLE广播包最多31字节名称太长会被截断一般建议不超过12个ASCII字符。改Service UUID稍微复杂一点因为涉及到GATT服务定义。例程中通常是一个SimpleService结构体里面包含Service UUID、Characteristic UUID和读写属性。你把这两个UUID换成自己产品定义的同时保证与App端一致。如果改完连不上八成是UUID的字节序写反了BLUENRG355MC协议栈里UUID是按小端模式存储的。4. 常见问题与排查技巧实录4.1 编译报错类问题速查错误现象原因解决办法cannot open source file bluenrg_lp_hal.hSDK路径未配置手动添加Drivers路径到Includeidentifier BLE_STATUS_SUCCESS is undefinedSDK版本不匹配检查是否用了BlueNRG-1/2旧SDKError: Flash Download failed - Cortex-M0烧录器连接不稳或芯片锁死用STM32CubeProgrammer全擦除后重烧No ST-LINK detectedUSB驱动问题重新安装ST-Link驱动或更换USB口编译报错里最坑的是第二种。互联网上很多资料是老的BlueNRG-1/2时代写的函数名和API都不一样。遇到这种报错别硬扛直接去SDK的Example目录翻BLE_Chat的代码照着改。4.2 连接不稳定或搜不到设备的排查路径搜不到设备第一反应不要怪芯片。按这个顺序排查开发板是否在广播状态用示波器或者逻辑分析仪看射频引脚有没有输出如果没有说明程序没跑到广播那一步。广播间隔是不是设得太长如果设成1000ms以上App扫描要等很久才能看到。调试时建议设为50ms~100ms。手机蓝牙缓存问题把手机蓝牙关掉再打开重新扫描。功率设置问题BLE_SetTxPower()的参数如果设置过低比如-20dBm隔远点就搜不到。调试时先用0dBm。连接成功但发送数据没反应一般是MTU大小或者ATT_MTU协商问题。BLUENRG355MC默认MTU是23字节如果上层一次写入超过20字节协议栈会分帧或者直接报错。你可以尝试修改MTU大小例程里通常有个CFG_MTU_SIZE可以配置成247。4.3 调试经验日志和事件回调是救命稻草BLE的调试和普通MCU不一样你很难实时看内部状态。最好的方式就是充分利用协议栈的事件回调函数把关键事件打印到串口上。我在自己的工程里习惯这样写static void Ble_Event_Callback(BLE_Event_T *evt) { switch (evt-type) { case BLE_GAP_EVENT_CONNECTED: printf(Connected, handle%04X\r\n, evt-evt.gap_evt.conn_handle); break; case BLE_GAP_EVENT_DISCONNECTED: printf(Disconnected, reason%02X\r\n, evt-evt.gap_evt.reason); break; default: break; } }这样一旦连接异常断开你至少能知道reason是多少再去对照手册找原因。ST的文档里有完整的错误码表很多问题查一下就可以定位。另外养成好习惯例程的工程里一般自带了HardFault_Handler的调试信息输出如果程序跑飞了串口会打出崩溃时的PC指针和寄存器值。把这个输出接上遇到死机不会一脸懵。5. 例程之外的进阶思路从demo走向产品5.1 如何基于例程搭建自己的工程结构跑完例程后你会发现官方Demo的代码风格是大一统的驱动、应用、协议栈回调全堆在几个文件里这样演示是没问题但做产品得重构。我建议按照这四层来组织你的代码app/ main.c ble_app/ ble_gap.c ble_gatt.c sensor/ sensor_read.c drv/ i2c_drv.c spi_drv.c应用层逻辑不要跟BLE回调混在一起。BLE回调只负责收数据收到之后通过一个消息队列或者标志位通知应用层去处理。这样后期维护和功能扩展都会轻松很多也方便跟RTOS集成。5.2 功耗、OTA与量产烧录需要提前考虑例程跑通只是第一步真做产品后面还有三座大山功耗调优、OTA固件升级、量产烧录。功耗调优这块前面提过要正确配置Sleep Mode。更关键的是要测量各阶段的电流广播态、连接态、休眠态分别应该对应什么量级做到心里有数。OTA升级是BLE产品的标配。ST的SDK里带了Bootloader和OTA服务例程但很多人只看了Peripheral例程不知道有OTA这回事。实际用起来要注意Flash分区Bootloader区、Image A区、Image B区还有交换区地址千万别写错写错了OTA一次就变砖。量产烧录方面BLUENRG355MC支持SWD烧录也支持UART Bootloader。如果生产量大建议用UART Bootloader STM32CubeProgrammer的命令行模式比人工一个个点界面快得多。ST的文档里写了BootROM的管脚配置上电前拉低特定引脚就能进入下载模式。这几块每一块都能单独写一篇我这里就点个方向提醒大家不要觉得demo跑通了就完事了。最后分享两个小技巧一个是关于调试效率的。BLUENRG355MC的BLE协议栈和射频部分比较吃时间如果你开着很多调试打印尤其是puts这种阻塞型输出会影响BLE时序导致连接变慢甚至断连。建议调试打印重定向成非阻塞DMA方式或者只在关键事件里打印短消息。另一个是关于芯片封装和天线匹配的。BLUENRG355MC本身不带天线需要外接匹配网络加天线。如果你用的是评估板上的参考设计直接抄是没问题的但如果自己画板千万不要随意变更射频走线和匹配器件参数。我第一次自己打板就吃了这个亏信号强度比评估板低了近10dBm后来老老实实按照参考设计重画才正常。射频这块没那么多玄学就是按参考来别自由发挥。整个折腾下来BLUENRG355MC这套例程的质量在BLE芯片里算中上水平能把官方demo从头到尾吃透基本的BLE开发能力就算立住了。接下来就是按自己产品的需求裁剪代码慢慢积累属于自己的工程模板了。本文还有配套的精品资源点击获取