简介：BES2700IHC-SDK源代码是恒玄科技针对BES2700IHC主控芯片推出的原生软件开发套件，面向TWS真无线耳机、OWS开放式耳机及蓝牙音频模块开发，适配官方开发板，覆盖驱动层、协议栈与应用层接口，可直接用于蓝牙连接管理、音频通路调试和低功耗策略配置。zip压缩包内共含2000个文件，主体为C/C++工程文件，包括1273个h头文件、351个c源文件、306个cpp实现文件及少量hpp，另有txt说明、shell脚本和PDF必读指南，整体约39.85MB，按功能目录组织，检索与移植方便。目前已有764位开发者学习或下载。代码集成了OWS低音补偿算法，可改善低频响应；蓝牙双连与抢连逻辑支持多设备保持连接、按优先级快速回连；BLE模块覆盖低功耗广播与控制。配合必读PDF中的安装与许可说明，开发者可快速搭建编译环境，弄清底层驱动到上层应用的完整链路，围绕连接稳定性、音质与功耗做二次开发，适合具备嵌入式C/C++基础、希望深入恒玄BES平台的产品研发工程师。

1. 拿到BES2700IHC SDK先别急着翻代码：先把编译和烧录跑通，后面的事才有意义

拿到恒玄BES平台的BES2700IHC SDK源码包，很多人的第一反应是去翻apps目录，想一口气把音频链路读完，结果往往是被几十个模块和跨文件回调绕晕，两天下来什么都没跑起来。我一般会反过来：先找编译脚本，把工具链装好，编译出一版镜像，烧进板子听到底噪，再回头读代码。这套SDK本质上是“芯片寄存器+协议栈+应用框架”三层叠在一起的工程包，能解决的是TWS耳机、运动耳机这类设备从开机到出厂的固件开发问题，适合有单片机基础、想从裸机过渡到RTOS项目的开发者。下面按“工程结构→编译环境→核心模块→踩坑→调试技巧”的顺序来拆，每段都能对着工程文件直接改。

2. 工程结构与编译环境：三天内把第一版固件烧进板子

2.1 代码目录：vendor、platform、apps 三个目录的职责边界

先不说代码逻辑，先看目录。BES2700IHC的SDK解开之后，顶层结构很清晰，最核心的几个目录职责如下：

这个分层不是随便分的。BES2700IHC是Cortex-M33内核，启动流程里vendor目录先完成时钟、电源和Flash初始化，然后把控制权交给platform的驱动初始化，最后apps里的业务代码才跑起来。如果你改按键逻辑，直接去apps的key handler里找；如果要换Flash型号，那要动vendor里的链接脚本和Flash驱动；如果要改串口波特率，则要去platform的uart配置里改。刚上手最忌讳的是到处搜代码，不知道去哪查文件。我的习惯是先用全局搜索定位“hal_trace”这个日志宏，找到日志输出所在的驱动文件，把它当作整个工程的“坐标系原点”。

提示：vendor目录里的芯片寄存器默认配置不要乱动，改之前先备份，否则启动流程容易跑飞，而且查起来没有日志，极其难受。

2.2 编译环境搭建：工具链版本不对是第一个翻车点

BES平台SDK依赖arm-none-eabi-gcc交叉编译链，而且对版本有要求。BES2700IHC是M33内核，带DSP扩展指令，旧版本工具链在编译某些DSP库代码时会出问题，常见的现象是编译通过但烧进去之后HardFault。我一般固定用GCC 10.x系列，装好之后把工具链路径写到环境变量里，然后在SDK根目录执行编译：

export BES_TOOLCHAIN_PATH=/opt/toolchain/gcc-arm-none-eabi-10.3-2021.10 export PATH=$BES_TOOLCHAIN_PATH/bin:$PATH cd vendor/bes2700ihc make TARGET=bes2700ihc_evb clean make TARGET=bes2700ihc_evb -j8

编译产物在build/bes2700ihc_evb/bin/目录下，其中带.bin后缀的是直接烧录用的镜像，.elf带符号表，给调试器在线调试用。每次改配置之后先执行make clean再全量编译，不要省这一步，因为BES的Makefile在增量编译时对头文件依赖跟踪不完整，容易把旧的宏定义带进去，编译出来的镜像行为很诡异。

常见报错是xxx.h: No such file or directory，但头文件明明存在。这是Makefile里用了相对路径，而编译命令是从vendor/bes2700ihc目录发起的。出现这种情况，检查Makefile顶部的BES_SDK_ROOT_DIR或SDK_ROOT变量，确认它指向SDK的顶级目录，通常是../../。不要把SDK放到带空格的路径下，Ninja和make都会出问题。

2.3 烧录与日志输出：第一次看到系统日志才算跑通

编译通过只是第一步，真正让板子跑起来才是“跑通”。BES2700IHC评估板一般通过USB调试下载器连接，烧录脚本封装在tools目录下。连接好板子之后，先确认设备管理器里能识别到调试器，然后执行烧录命令：

./tools/download.sh bes2700ihc_evb \ build/bes2700ihc_evb/bin/bes2700ihc_evb.bin

download脚本会先自动进入下载模式，再通过USB把固件写到Flash里。这一步如果卡在等待设备响应，先拔掉串口线只保留USB下载线，排除供电冲突。烧录成功之后板子会自动重启，这时打开串口工具看日志。BES2700IHC的调试串口默认是UART0，波特率常见默认配置是921600，在Linux下用minicom：

minicom -D /dev/ttyUSB0 -b 921600

如果上电后能看到[TRACE]或者类似系统启动日志输出，说明整个工具链已经通了。日志通道是后面所有排查工作的命脉，我建议第一天就把日志搞稳定，日志线不要随便拔，后面调连接参数、查功耗、看崩溃信息全都要靠它。

3. 核心模块改机实战：连接参数、音频增益和功耗挡位

3.1 蓝牙连接参数：广播间隔和连接间隔改对了，掉线率立刻下来

TWS耳机最常见的体验问题就是“偶尔断连”和“连接慢”。这两个问题基本都出在蓝牙连接参数上。BES平台里，广播参数在应用层初始化时配置，广播间隔的单位是0.625ms，这是一个必须记住的常量。

/* apps/bluetooth/app_ble_adv.c */ const struct ble_adv_param adv_param = { .adv_interval_min = 160, /* 广播间隔最小值：160 * 0.625ms = 100ms */ .adv_interval_max = 240, /* 广播间隔最大值：240 * 0.625ms = 150ms */ .adv_type = BLE_ADV_TYPE_IND, /* 可连接无定向广播 */ .channel_map = 0x07, /* 三个广播信道全开 */ };

广播间隔不是越小越好。把广播间隔调到50ms，手机连接速度确实快，但广播功耗翻倍，待机时间明显变短；调到200ms以上功耗降下来了，但偶尔出现“开盖连不上”的体验问题。我的经验是TWS耳机用100ms左右比较平衡，真要做长续航待机场景才考虑150ms以上。

连接参数同样重要，尤其要关注连接间隔和超时时间。连接间隔单位是1.25ms，超时时间单位是10ms：

struct ble_conn_param conn_cfg = { .conn_interval_min = 24, /* 30ms */ .conn_interval_max = 40, /* 50ms */ .slave_latency = 4, /* 设备侧可跳过4个连接事件 */ .supervision_timeout = 200 /* 2000ms，链路超时 */ };

这里有一个取舍：slave_latency调大可以让设备在空闲时少起来收包，省电效果明显，但代价是数据延迟变大，左右耳同步可能会出问题。supervision_timeout必须大于有效连接间隔的3倍，否则会误判链路超时导致频繁断开。

3.2 音频通路：从I2S到DAC的增益链路

BES2700IHC的音频通路可以简单理解为：外部音频源（I2S/PCM）进来，经过DSP做EQ和降噪处理，然后送到DAC转换成模拟信号，再经过PGA放大输出到功放或直接驱动耳机。PGA增益是最常调的参数，因为它直接决定音量大小和底噪水平。

/* platform/drivers/audio/audio_pga.c */ struct audio_pga_cfg pga_cfg = { .input_gain_db = -3, /* 输入增益，负值防止过载削波 */ .output_gain_db = 0, /* 输出增益，默认0dB */ .digital_gain = 108, /* 数字增益，0.5dB步进，108对应+6dB */ };

数字增益开太大，耳机里会有明显的底噪，尤其安静环境下“嘶嘶”声很烦人。PGA增益我一般优先把模拟增益调到位，再一点点补数字增益。调完之后用示波器看DAC输出波形，确认削波情况，不能只靠耳朵听，耳朵在疲劳之后会骗人。还有个容易忽略的点：I2S输入的对齐格式和采样率必须和DSP配置一致，否则听起来是正常音量但声音发闷，像是隔了一层布。

3.3 功耗调优：让sleep模式真正生效

耳机产品的续航是卖点，BES平台的功耗管理分几个挡位：

进去sleep模式之前，要明确哪些引脚能唤醒系统。通常按键是主要唤醒源：

struct sleep_wakeup_cfg wake_cfg = { .wakeup_sources = WAKEUP_SRC_GPIO | WAKEUP_SRC_TIMER, .gpio_index = IO_GPIO_6, /* 按键唤醒脚 */ .gpio_polarity = GPIO_POL_LOW, /* 按下为低电平 */ .sleep_timeout_ms = 3000, /* 空闲3秒后进入sleep */ };

调功耗时必须用万用表串在电池供电回路上实测休眠电流，不要只看SDK文档写的理论值。实际项目里“标称微安级但实测几毫安”的坑很常见，原因大多是某个GPIO悬空漏电或者串口在进sleep前没关掉。后面第四章专门讲这个坑。

4. 避坑记录：BES2700IHC调试中的五个常见坑

4.1 编译与烧录相关的两个坑

坑一：编译报错找不到头文件，但文件明明在

现象：执行make之后，提示xxx.h: No such file or directory，去文件系统里搜索，头文件确实存在。

原因：工程Makefile在增量编译时没有正确解析头文件依赖路径，或者工具链路径覆盖不全，编译器找不到SDK根目录。最常见的是SDK路径带空格，或者是BES_SDK_ROOT_DIR环境变量没指向顶级目录。

解决：先执行make clean，然后用echo $BES_SDK_ROOT_DIR确认路径，再把SDK挪到无空格路径下重新编译。如果还报错，打开Makefile搜-I$(xxx)，手动把缺失的include路径补进去。我习惯于把所有编译命令封装成一个build.sh，把环境变量写死在脚本里，避免每次开新终端重新设置。

坑二：烧录时设备管理器识别不到下载器

现象：点击烧录脚本后一直提示“waiting for device”，电脑端设备管理器里看不到下载器设备。

原因：第一是USB驱动没装，第二是目标板供电不稳，下载器被板子倒灌电流拖到无法枚举。

解决：先单独给下载器供电，不接目标板看能否被识别，能识别就是目标板供电问题，接上目标板之前先确认板上电源指示灯正常。排除供电问题之后装驱动。这个坑在台式机前面板USB口特别容易触发，尽量用机箱后置USB口，供电更稳定。

4.2 射频与音频相关的两个坑

坑三：手机能搜到耳机，但一连接就秒断

现象：手机蓝牙列表里能看到设备名称，点击配对之后过两三秒就断开，偶尔连上一次但信号极差。

原因：高频晶振频偏太大，协议栈解包失败。这个是BES平台的老大难问题，很多工程师第一次遇到都会当成软件问题去查连接状态机，查了两天发现是硬件玄学——晶振负载电容不对导致频偏超标。

解决：用频谱仪或SDK自带的频偏校准工具测量射频指标，确认频偏在±20ppm以内。如果频偏超标，检查晶振负载电容匹配是否和晶振规格书一致，改完硬件之后重新校准并回读频偏值。千万别在代码里硬扛频偏问题，软件补偿只是掩耳盗铃。

坑四：开机后有底噪，音量越小越明显

现象：耳机在安静环境下有“嘶嘶”声，音量调低后底噪反而更明显，音量大时底噪被掩盖。

原因：PGA增益开得太大，数字增益被拉满，噪声本底被整体抬高；或者DAC输出路径上的滤波电容虚焊、地平面铺得不好。

解决：把PGA输出增益降到-6dB，再把数字增益补偿到正常音量，对比底噪是否改善。如果底噪依旧，用示波器看DAC输出的噪声波形，检查模拟电源的纹波，必要时在DAC输出到功放之间加RC滤波。这个坑最考验耐心，得一级一级查。

4.3 功耗与唤醒相关的坑

坑五：实测休眠电流是标称值的几十倍

现象：文档写sleep模式下功耗可以到微安级别，实测却有3mA左右，续航直接砍半。

原因：睡眠前某个GPIO处于悬空状态，引脚在高低电平之间反复翻转产生漏电；或者调试串口在进入sleep前没有被关闭，UART模块还在工作。

解决：写一个“睡眠前检查”函数，在进入sleep之前把所有未使用的GPIO统一配置为输入下拉，确认UART关闭、DMA停止。然后逐个外设排查：关掉一个外设测一次电流，用二分法快速定位漏电源。这个坑之所以排第一，是因为它不影响功能，机器能正常用，但续航数据永远不对，直到量产才发现。

5. 一个实用技巧：用trace日志定位偶发断连问题

偶发断连是蓝牙耳机开发中最难复现的问题——你开着日志盯一上午都不出现，刚合上电脑准备下班，测试那边就报“断了三次”。这种问题不能靠肉眼看，必须把日志通道做成“黑匣子”。

第一步，加大日志缓冲区。BES平台的trace日志底层是一个环形缓冲区，默认大小可能只有几KB，偶发问题日志打印一多就被覆盖了。我一般把缓冲区放大到32KB以上：

/* platform/drivers/hal/hal_trace.c */ #define HAL_TRACE_BUF_SIZE (32 * 1024)

第二步，在断连回调里把断开原因码打出来。蓝牙协议栈在断连时会返回一个reason code，直接对应HCI层的错误码，这是定位断连问题最关键的线索：

void app_ble_disconnect_cb(uint8_t reason, uint16_t conn_handle) { /* 断连原因码：0x08是链路超时，0x13是对端主动断开 */ TRACE(2, "[DISCONN] handle=%d reason=0x%02x", conn_handle, reason); TRACE(1, "[RSSI] last_rssi=%d", app_ble_get_rssi(conn_handle)); }

reason code是0x08说明链路超时，问题大概率出在连接参数或射频环境；reason code是0x13说明对端主动断开，要去看手机端的操作行为；如果断连前RSSI值急剧下降，则是天线匹配或遮挡问题。日志带上时间戳之后，把断连时刻和电流波形对齐，能进一步区分是软件卡死导致的看门狗重启，还是真的射频断链。

我自己就翻过一次车：为了压功耗把连接间隔从30ms调大到50ms，测下来功耗确实降了，结果压测两天之后偶发断连率从0.1%升到1%，回退参数之后恢复正常。从那以后我每次改连接参数，都会强制走一遍“改参数→抓log→量电流→压测48小时”的流程，不再相信自己的“觉得没问题”。这个习惯帮我省了很多半夜改代码的时间，希望帮到你。

本文还有配套的精品资源，点击获取