简介：这份资源是ST公司BLUENRG355MC蓝牙低功耗SoC的配套例程包，面向物联网与可穿戴设备开发者，尤其是希望快速上手BlueNRG-LP系列、掌握BLE协议栈配置与低功耗设计的中高级嵌入式工程师。包内共约2000个文件，以C源码与头文件为核心，辅以hex、bin固件、ewp/uvprojx等IAR与Keil工程文件、icf与sct链接脚本、html文档及png图示，压缩包约264.55MB，覆盖初始化配置、连接管理、GATT数据传输、功耗控制与中断事件处理等关键模块。已有344人学习下载。借助这些例程，读者可对照官方SDK理解BLE协议栈分层结构，参考HCI命令交互与自定义服务实现，并复用现成的工程模板与链接配置，快速将BLUENRG355MC集成到智能家居、健康监测等实际产品中。
1. 拿到 BLUENRG355MC 例程包，先别急着烧录
如果你手里正捏着一块基于 BLUENRG355MC 的板子，或者刚接手一个 BlueNRG-LP 系列的低功耗蓝牙项目，大概率会遇到一个很现实的问题：官方 SDK 里例程一大堆，但真要从零跑通一个能用的 BLE 从机，光靠翻文档得折腾好几天。BLUENRG355MC 这颗芯片属于 ST 的 BlueNRG-LP 家族，主打低功耗蓝牙 5.x，内置 Cortex-M0+ 内核，Flash 和 RAM 的配置在同级里算宽裕，适合做传感器节点、穿戴设备、工业遥控这类对功耗敏感的场景。这份例程包的价值就在于，它把 GPIO 翻转、UART 收发、BLE 广播、连接参数配置这些基础操作都拆成了独立工程，你不需要从空白工程开始搭环境，直接拿一个最接近需求的例程改，能省掉大量底层初始化的时间。适合谁？刚接触 BlueNRG-LP 的嵌入式新手，以及从其他 BLE 平台迁移过来、想快速摸清 ST 这套工具链脾气的老手。
2. 例程包的结构与工具链选型：为什么不是 Keil 就是 IAR
2.1 例程目录里到底放了什么
拿到一个 BlueNRG-LP 的例程包，第一件事是看目录结构。常见的组织方式是按功能分文件夹，比如BLE_Examples、Peripherals_Examples、Radio_Examples这几大类。BLE 下面又会细分Beacon、Chat、HeartRate、SensorDemo等角色例程。每个例程文件夹里通常包含Inc、Src、EWARM（IAR 工程）、MDK-ARM（Keil 工程）以及一个readme.txt。Src里的main.c是入口，app_bluenrg.c或类似命名的文件负责 BLE 协议栈的初始化和事件回调。Inc里放的是hci.h、bluenrg_lp_api.h这类协议栈头文件，不要改它们，改了容易和库版本对不上。
一个典型的 BLE 从机例程，核心文件就三个：main.c做时钟和 GPIO 初始化，app_bluenrg.c里调用aci_gap_init设置设备名和广播参数，bluenrg_lp_it.c处理中断。剩下的system_bluenrg_lp.c是 ST 提供的系统级初始化，一般不动。如果你看到例程里还有sensor.c或led.c，那是外设驱动，按板子原理图改引脚就行。
2.2 Keil 和 IAR 怎么选，别在这件事上纠结太久
ST 的 BlueNRG-LP SDK 同时提供 Keil MDK 和 IAR EWARM 的工程文件。选哪个？如果你公司或团队已经有 Keil 的授权，直接用 Keil，因为 ST 的很多应用笔记和社区回答都是基于 Keil 的，遇到问题搜起来方便。IAR 的优势在编译优化和调试体验，但 BlueNRG-LP 的 IAR 工程有时候需要手动调整链接脚本里的 Flash 起始地址，新手容易在这里翻车。
我一般会建议：先打开 Keil 工程，确认能编译通过、能下载、能跑起来，再考虑要不要换 IAR。不要一上来就两个都装，环境变量和 Pack 包容易打架。Keil 需要安装 BlueNRG-LP 的 Device Family Pack，IAR 需要安装对应的 CMSIS 支持包，这些在 SDK 的Utilities文件夹里都有说明。
2.3 用命令行编译一次，确认工具链没问题
在打开 IDE 之前，可以先在命令行里跑一次编译，确认编译器路径和头文件搜索路径都是对的。以 Keil 为例，假设你装的是 MDK，可以用UV4.exe做命令行编译：
# 进入例程的 MDK-ARM 目录 cd BLUENRG_LP_Examples/BLE_Examples/Beacon/MDK-ARM # 用 Keil 命令行编译，-b 表示 build，-j0 表示不弹窗 UV4.exe -b Beacon.uvprojx -j0 -o build_log.txt # 查看编译结果 cat build_log.txt这段命令的作用是让 Keil 在后台完成一次完整编译，输出日志到build_log.txt。如果日志最后出现0 Error(s), 0 Warning(s)，说明工具链和工程配置没问题。参数-j0是禁止弹出 GUI 窗口，适合脚本化操作。注意UV4.exe的路径要加到系统 PATH 里，或者写全路径。如果报错说找不到armcc，说明 Keil 的编译器组件没装全，重新跑一遍安装程序，勾选 ARM Compiler 选项。
编译通过之后，用 ST-LINK 或 J-Link 下载。BlueNRG-LP 支持 SWD 调试，接线就四根：VCC、GND、SWDIO、SWCLK。下载完复位，如果板子上有 LED，应该能看到例程里定义的闪烁模式。
3. 从 Beacon 例程改出一个自定义广播：参数怎么设、坑在哪
3.1 广播间隔和发射功率的取舍
Beacon 例程是最适合拿来改的起点，因为它只做广播，不建立连接，代码路径短，出问题容易定位。打开app_bluenrg.c，找到aci_gap_set_discoverable或aci_gap_set_non_discoverable的调用。广播间隔由adv_interval_min和adv_interval_max两个参数控制，单位是 0.625 毫秒。比如你要设 100 毫秒的广播间隔，就填 160。
发射功率在aci_hal_set_tx_power_level里设置，BlueNRG-LP 支持从 -20 dBm 到 +8 dBm 的档位。功率越高，广播距离越远，但功耗也越大。如果是纽扣电池供电的传感器，建议设在 0 dBm 到 +4 dBm 之间，配合 500 毫秒以上的广播间隔，实测能撑几个月。如果是对响应速度要求高的遥控器，可以设 +8 dBm 和 20 毫秒间隔，但电池寿命会明显缩短。
// 设置广播间隔为 100ms（160 * 0.625ms） uint16_t adv_interval_min = 160; uint16_t adv_interval_max = 160; // 设置发射功率为 +4 dBm aci_hal_set_tx_power_level(1, 4); // 配置广播数据 uint8_t adv_data[] = { 0x02, 0x01, 0x06, // Flags: LE General Discoverable, BR/EDR Not Supported 0x03, 0x03, 0xAA, 0xBB, // 16-bit UUID 0x05, 0x09, 'T', 'E', 'S', 'T' // Complete Local Name }; aci_gap_set_discoverable(ADV_IND, adv_interval_min, adv_interval_max, PUBLIC_ADDR, 0, NULL, 0, sizeof(adv_data), adv_data);这段代码里，aci_gap_set_discoverable的第一个参数是广播类型，ADV_IND表示可连接的非定向广播。如果你只想广播不想被连接，改成ADV_NONCONN_IND。PUBLIC_ADDR表示使用芯片出厂固化的公共地址，如果想用随机地址，改成RANDOM_ADDR并提前调用aci_hal_write_config_data写入随机地址。广播数据里的0x02, 0x01, 0x06是固定格式，表示设备支持 BLE 且不可被 BR/EDR 发现，不要随意改。
3.2 中断优先级和协议栈回调的配合
BlueNRG-LP 的 BLE 协议栈跑在独立的内核上，和 Cortex-M0+ 通过 SPI 或共享内存通信。中断优先级配错，会出现广播发不出去、连接后立刻断开这类玄学问题。在bluenrg_lp_it.c里，BLE_IRQHandler的优先级要设成最高，比 SysTick 和 UART 都高。如果用了 FreeRTOS，还要注意协议栈回调里不能调用阻塞式 API。
常见做法是在main.c里调用NVIC_SetPriority(BLE_IRQn, 0)，把 BLE 中断设为最高优先级。然后检查aci_gap_set_discoverable的返回值，如果不是BLE_STATUS_SUCCESS，说明协议栈还没初始化完，需要等HCI_RESET完成后再调用。这个等待过程通常放在app_bluenrg_init里，用while循环轮询hci_read_event直到收到HCI_COMMAND_COMPLETE_EVENT。
3.3 用手机 App 验证广播是否正常
改完代码烧录后，用手机上的 nRF Connect 或 LightBlue 扫一下，看能不能看到你设置的设备名和 UUID。如果扫不到，先确认板子的天线匹配电路有没有问题，再检查广播数据长度是否超过 31 字节。BLE 4.x 的广播包最大 31 字节，BLE 5.x 可以用扩展广播突破这个限制，但 BlueNRG-LP 的例程默认还是传统广播。超过 31 字节会直接返回错误，但有些版本的协议栈不报错，只是广播不出去，这点特别坑。
如果手机能扫到但连不上，检查aci_gap_set_discoverable的第二个参数是不是设成了ADV_NONCONN_IND。另外，连接参数里的conn_interval_min和conn_interval_max也要设合理，太短会增加功耗，太长会导致手机端操作卡顿。一般设 30 毫秒到 50 毫秒比较均衡。
4. 避坑与排查：BlueNRG-LP 例程里最容易翻车的五个点
4.1 编译通过但下载后没反应
现象：Keil 里编译零错误零警告，ST-LINK 也显示下载成功，但板子上的 LED 不闪，手机也扫不到广播。
原因：BlueNRG-LP 的 Flash 起始地址和 Keil 工程里的 IROM 配置不匹配。有些例程默认从0x10040000开始，但实际芯片的 Flash 映射可能不同。
解决：打开 Keil 的Options for Target，在Target标签页里核对IROM1的起始地址和大小。参考 SDK 里system_bluenrg_lp.c中的FLASH_BASE定义，确保一致。改完重新编译下载。
4.2 广播数据里设备名显示乱码
现象：手机 App 里能看到设备，但名字是一串乱码或者只显示前几个字符。
原因：广播数据里的长度字段写错了。比如0x05, 0x09, 'T', 'E', 'S', 'T'表示长度 5 字节，类型 0x09（Complete Local Name），后面跟 4 个字符。如果实际写了 6 个字符但长度字段还是 5，就会截断或乱码。
解决：数清楚每个 AD 结构的字节数，长度字段 = 类型字段 1 字节 + 数据字节数。设备名建议不超过 10 个字符，留空间给其他 AD 结构。
4.3 连接后频繁断开
现象：手机能连上，但几秒后就断开，反复重连。
原因：连接参数里的conn_latency设得太大，或者从机延迟响应了协议栈的时钟同步事件。
解决：把conn_latency设为 0，conn_interval_min和conn_interval_max设成相同值，supervision_timeout至少设为conn_interval的 6 倍。另外检查aci_gap_connect的回调里有没有及时调用aci_gap_slave_security或类似的安全请求函数。
4.4 低功耗模式下电流降不下来
现象：进入睡眠模式后，实测电流还是毫安级，达不到微安级。
原因：GPIO 没配置成模拟输入或下拉，浮空的引脚会漏电。另外，UART 和 SPI 的外设时钟没关。
解决：在进入低功耗前，把所有未使用的 GPIO 设为GPIO_MODE_ANALOG，关闭 UART、SPI、I2C 的时钟。BlueNRG-LP 的aci_hal_set_sleep_mode可以配置睡眠深度，但需要配合PWR_EnterSTOPMode一起用。实测中，把调试用的 SWD 引脚也关掉，能再省几十微安。
4.5 例程里的 UUID 和手机端对不上
现象：手机 App 按例程里的 UUID 去读特征值，返回GATT_INVALID_HANDLE。
原因：BlueNRG-LP 协议栈在添加服务时，UUID 的字节序和手机端解析的字节序相反。比如 16 位 UUID0xAAAB，在代码里要写成{0xAB, 0xAA}。
解决：统一用aci_gatt_add_service和aci_gatt_add_char的返回值来操作句柄，不要硬编码 UUID。如果必须用 UUID 匹配，在手机端把字节序反过来试一次。
5. 进阶：用例程里的 Radio 测试代码做射频校准
例程包里通常还有一个Radio_Examples文件夹，里面是射频测试代码，能发单载波、调频、收包统计。这个比 BLE 例程更底层，适合做产线校准或天线匹配调试。我一般会在板子打样回来后，先跑一遍Radio_Test，用频谱仪看发射功率和频偏，确认天线匹配网络没问题，再去调 BLE 协议栈的参数。
具体操作是打开Radio_Test工程，在main.c里选择测试模式。比如要发单载波，调用radio_set_tx_test_mode，设置信道和功率，然后芯片会持续发射。用频谱仪接上天线耦合器，看中心频率是不是 2.402 GHz、2.440 GHz 这些 BLE 信道频点。如果频偏超过 ±50 kHz，检查晶振的负载电容匹配。
// 设置射频测试模式：单载波发射，信道 0（2402 MHz），功率 0 dBm radio_set_tx_test_mode(0, 0); // 延时 10 秒，让频谱仪读数稳定 for (volatile uint32_t i = 0; i < 10000000; i++); // 退出测试模式 radio_set_tx_test_mode(0xFF, 0);这段代码里，radio_set_tx_test_mode的第一个参数是信道号，0 对应 2402 MHz，39 对应 2480 MHz。第二个参数是功率档位，0 表示 0 dBm。退出时把信道设为0xFF表示停止发射。注意这个测试模式会绕过协议栈，直接控制射频前端，所以不要在正常 BLE 连接中使用。
还有一个实用技巧：用Radio_Test里的收包统计功能，可以测出接收灵敏度和丢包率。把两块板子分别设成发射和接收，距离拉远，看丢包率什么时候超过 1%。这个数据比看数据手册上的灵敏度指标更真实，因为包含了天线和匹配电路的损耗。
从那以后我每次拿到新的 BlueNRG-LP 板子，都会先跑一遍 Radio 测试，确认射频链路没问题，再去调 BLE 例程。这个习惯帮我省掉了很多“以为是代码问题、其实是天线没匹配好”的后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
