自制蓝牙HCI Dongle全流程：从芯片选型到协议栈集成与调试实战

做蓝牙开发这几年，我前前后后折腾过不少方案，串口模块、透传芯片、BLE SoC都碰过，但真正让我觉得“卧槽，原来是这么回事”的，还是自己从头做一颗蓝牙HCI Dongle。这东西听起来不起眼，插在电脑上就是个小U盘，但它其实是你理解蓝牙协议栈最锋利的切入点。从芯片选型开始，到PCB打样，再到把协议栈跑起来，整个过程把蓝牙的Host和Controller分界、HCI命令交互、驱动的坑、射频布局的讲究全串起来了。这篇就把我完整的实操过程、选型逻辑和踩过的坑都写出来，给想自己做蓝牙适配器或者正在做协议栈集成的朋友当个参考。

1. HCI与Dongle，先把底层架构彻底搞明白

很多人一开始就纠结买什么芯片、用什么开发板，我觉得这是顺序搞反了。做HCI Dongle之前，你首先得把蓝牙协议栈的分层结构吃透，尤其是HCI这个夹在Host和Controller之间的标准接口，它决定了你这个Dongle到底是个什么东西、能干什么活。

1.1 HCI在蓝牙协议栈里到底处于什么位置

蓝牙协议栈从物理层往上，可以分为两大块：Controller和Host。Controller负责底层射频收发、基带处理、链路管理，也就是我们常说的“硬件部分”；Host负责L2CAP、SDP、GATT、ATT这些逻辑功能，以及上层的应用Profile，偏软件。而HCI，Host Controller Interface，就是这条分界线上的标准化通信协议，定义了Host怎么向Controller发命令、Controller怎么回报事件、两边怎么传数据。

我用一个不那么严谨但很好懂的类比：Controller是手脚，负责把动作做出来；Host是大脑，负责想清楚要干什么；HCI就是连接大脑和手脚的神经。你伸手拿杯子这个动作，大脑不会去控制每一块肌肉的收缩，它只需要发出“拿起杯子”的指令，脊髓和周围神经去执行。蓝牙也一样，应用层不会直接去操作射频寄存器，它通过HCI命令告诉Controller“开始广播”“发起连接”，Controller做完后通过HCI事件告诉Host“广播已开始”“连接已建立”。

那这就引出一个关键区别：你平时接触的HC-05、HC-06、JDY-31这类串口蓝牙模块，本质上不是HCI Dongle。这些模块把整个Host协议栈甚至SPP串口Profile都封装在了模块内部，你直接用AT指令控制，模块自己会处理配对、连接、数据透传。而HCI Dongle只实现了Controller部分，它把原始的HCI接口暴露出来，Host侧的协议栈完全由你接入的设备来提供，比如电脑上的BlueZ、Windows蓝牙栈、或者你自己写的嵌入式协议栈。

1.2 为什么HCI Dongle更具可玩性

直接买现成的USB蓝牙适配器插上就能用，为什么还要自己做HCI Dongle？我自己的体会是，它带来的是协议栈层面的完全掌控权。

首先是Host侧协议栈可替换、可定制。你有自己的私有GATT服务、想做Mesh组网、想用HCI层直接处理广播数据，比如热词里那个“蓝牙测距”的需求，基于到达角度或到达时间差的测距方案很多就是在HCI层扩展厂商Vendor命令来实现的。这时候厂商封装好的串口模块根本不够用，你只能走到HCI这一层，甚至要下探到Controller的厂商专有命令。

其次是跨平台一致性。HCI是个标准接口，同样的Dongle，插到Linux上由btusb驱动接管，交给BlueZ；插到Windows上由微软蓝牙栈或厂商驱动接管；接到嵌入式设备上可以通过UART HCI挂到自己的协议栈。硬件不用动，换的是Host侧软件。这种“同一个控制器，随便配主机”的玩法，是集成式模块给不了的。

还有一点是做原型验证的效率极高。比如你在调试BLE连接参数对吞吐和功耗的影响，用HCI Dongle配合抓包工具，你可以非常直观地看到主机下发的连接参数更新请求、控制器的响应、每一个数据包的收发时机，定位问题比在黑盒模块里靠猜要快得多。所以如果你是想深入蓝牙协议栈本身，或者要做一个支持各类系统、长期维护的蓝牙适配器产品，HCI Dongle是不二选择。

2. 芯片选型：参数表之外我才真正关注的东西

芯片选型是决定这个Dongle命运的第一步，也是最容易翻车的一步。市面上能做蓝牙HCI Dongle的芯片方案其实不少，但每一款的脾气都不一样。我整理了一下自己接触过的方案，先说结论：如果是做量产产品对外卖，优先考虑驱动兼容性和供货稳定性；如果是自己做来玩或者做嵌入式集成，那就看你手里协议栈的适配程度了。

2.1 主流方案盘点与我的选择逻辑

我列一个简单的对比表，这些都是我自己实际用过的或者被客户问过最多的一批：

如果是做一款通用型的PC蓝牙Dongle，芯片方案我会优先考虑CSR8510这类老牌型号，因为它的HCI命令规范、驱动历史、参考资料都极其丰富，网上能搜到大量案例，这点对新手极其友好。你在驱动层面遇到问题，搜“csr8510 a10蓝牙驱动”“win7插入蓝牙后没反应”这些真实搜索词，很容易找到前人的解决方案。但它有个问题：市面上这颗料的水太深了，原装、翻新、打磨片、散新片混在一起，采购的时候一定要找正规渠道，不然做出来的板子性能飘忽，今天能连明天连不上，出了问题你根本分不清是设计问题还是芯片问题。

如果你打算在Dongle上做私有协议扩展，那就别考虑老芯片了。我后来自己做的一款Dongle就直接选了nRF52840，因为它支持USB，官方有USB HCI的参考实现，你可以在Controller内核基础上加自己的Vendor命令，比如做私有测距指令、扩展广播数据注入，这些都是CSR这种封闭方案没法干的。

2.2 选型时需要重点考察的五个维度

我每次做选型评估，不怎么看厂商宣传页，重点考察的是下面五件事：

第一，驱动成熟度。这东西很难光靠看文档判断，最好的办法就是买一个公板或者找到同芯片的现成Dongle，插到Win10、Win11、Ubuntu、Android开发板上各试一遍。驱动没跟上，芯片再好也是白搭。特别是很多低价芯片，Linux内核里压根没有原生驱动，你得去扒厂商那一坨半死不活的源码，极其痛苦。

第二，HCI传输层支持。你是做USB Dongle还是UART Dongle？USB方案要注意芯片是内置USB PHY还是需要外接，枚举时是走HCI类设备还是自定义设备，这会直接影响驱动加载方式。UART方案则要关注波特率范围、硬件流控支持，还有固件启动时进入下载模式和运行模式的引脚区分，这些细节才是决定调试顺不顺的关键。

第三，射频性能。发射功率、接收灵敏度、天线接口方式，这几项直接决定你Dongle能连多远。但是坦白讲，芯片本身的数据差异没有你想象的大，更大的差异在PCB天线设计和匹配电路上。所以选型时我更看重芯片有没有成熟的参考设计，天线匹配有没有给出元件值和走线建议，这能省掉很多射频调试的功夫。

第四，厂商资料的完整度。有没有公开的HCI命令手册？有没有Linux驱动的补丁或者主线支持情况？有没有PDL、参考原理图？有些厂商的SDK是签了NDA才给你看，对个人开发者或者小团队极不友好。以我的经验，资料开放度往往决定你的开发周期，选错了能在文档上卡你一个月。

第五，供货和长期可用性。这一点我以前吃过亏，辛辛苦苦画完板子、调通固件，结果芯片停产了，只能重新选型再来一遍。所以选型表里一定要加一列“生命周期状态”，优先选工业级、生命周期长、甚至有两家pin兼容可替换的方案，既给自己留后路，也给客户吃定心丸。

2.3 我在选型过程中踩过的真实坑

这里多写一点自己的教训。

第一个坑是驱动被系统自动更新搞挂。有一版我用了某颗Realtek方案，在旧版本驱动下一切正常，结果Windows推送了一次大版本更新后，蓝牙模块直接失踪，设备管理器里出现个黄叹号，重新安装旧驱动也被系统拦着不让装。后来查了才知道是新旧驱动之间inf签名和版本兼容有问题，解决方式是从设备管理器里彻底卸载设备并“删除驱动程序软件”，再装老版本。这类问题在搜“win10蓝牙删除设备删不掉”的时候特别常见，其实不少就是驱动残留导致的。所以选型时，我会特别在意芯片厂商对微软WHQL认证的跟进速度。

第二个坑是PID/VID混乱导致的识别异常。当你用同一个PCBA做了多个SKU时，如果固件里PID/VID配置错了，系统可能把Dongle识别成其他设备，甚至挂错驱动。我就遇到过把Dongle识别成U盘的情况，当时以为是硬件故障，折腾半天，其实就是VID写错了。

第三个坑是采购渠道不明。小批量打样时你可能觉得淘宝随便买几颗芯片没什么，但蓝牙射频这种模拟特性很强的器件，对晶圆批次、封装工艺是很敏感的。同一型号不同批次，天线匹配可能都要微调。所以如果是做正式项目，一定要走正规代理商渠道，保留批次信息，样品阶段就锁料。

3. 硬件设计实操：从电路原理图到射频布局

选好芯片之后，就进入硬件的实际操作阶段了。很多人觉得做Dongle很简单，不就是USB转串口、串口接个蓝牙芯片吗？实际画起来，里面的门道一点都不少。我按照自己做板子的顺序，把关键点拆开讲。

3.1 最小系统电路怎么搭

先说USB接口型Dongle的最小系统。以带USB的蓝牙芯片为例，整板核心就是电源、晶振、USB差分线、射频前端和天线。

电源部分，芯片的VDD一般需要3.3V，如果USB总线是5V输入，板上需要一颗LDO或者DC-DC把电压降压并滤波。Dongle这种应用电流不大，LDO就够用，但要注意两点：一是输入输出压差和热阻，别让LDO在小外形封装上过热；二是电源纹波对射频的影响，VDD上的高频纹波会耦合到射频路径里，影响接收灵敏度。所以供电走线上我习惯加一颗10uF储能电容，紧贴芯片电源引脚再放一颗0.1uF高频去耦，这个组合基本能压住绝大多数纹波问题。

晶振部分，蓝牙芯片对参考时钟精度有要求，BLE模式下一般要求±20ppm甚至±30ppm以下。千万别图便宜买精度不够的晶振，否则会出现连接不稳定、广播不被发现这类莫名其妙的问题。晶振旁边两个负载电容的具体值要按晶振规格书来选，我通常是先按规格书推荐的典型值贴板，再在射频调试时用频谱仪看频偏微调。

USB接口部分，D+和D-要走差分对，尽量短，保持阻抗连续，并且做ESD防护。实时上很多Dongle因为偷面积，把ESD防护芯片省掉了，这在产品化时是个隐患。插拔USB时人体静电很常见，一旦打坏芯片，返修成本比你加一颗ESD防护芯片高得多。所以我的建议是：哪怕自己做样机，这个钱也不要省。

再补充一点，如果你做的是UART HCI模式的Dongle，电路上要把芯片的UART引脚引出来，并且加上电平适配。很多蓝牙芯片是1.8V的IO电平，和3.3V或5V的主控对接时需要电平转换，不然串口数据乱码、HCI命令发送无响应都是家常便饭。

3.2 天线与射频布局

天线部分我单独拿出来说，是因为这决定了你的Dongle是“能用”还是“好用”。很多做过射频的同行应该深有体会：一套设计里，芯片和电路照抄参考设计都没问题，但只要天线区域乱铺地、走线过长、距离金属件太近，信号指标就直线下滑。

PCB天线或者陶瓷天线周围要保持净空，天线下方不能铺铜，天线周围一圈也不要放器件。匹配电路的电感电容要靠近天线馈点放，并且严格按参考设计走。有些芯片方案会给出π型匹配网络，我一般会预留三个焊盘位置，先不贴元件，等实测时再根据回波损耗和发射功率去调整匹配。这样做的好处是，即使layout和参考设计有细微差异，也有容错空间。

如果你用的方案支持外接天线，比如IPEX座子，Dongle外壳上要预留天线位，并确保天线可以伸出来或者贴在壳体上，不能把天线塞进小板子下面。金属外壳对蓝牙的衰减非常明显，产品设计如果必须用金属壳，一定要预留天线窗口。

还有一点，Dongle插在电脑USB口上，天线离电脑外壳很近，电脑外壳的金属和内部主板的接地层会影响天线的谐振频率。我实测过同一套Dongle插在台式机前面板和USB延长线上，扫描距离能差个百分之二三十。所以前期的天线调试必须在实际使用场景下测，不要只是空板上测了就完事。

3.3 结构件和可量产性的考虑

到了产品化阶段，结构件对蓝牙射频的影响比你想的大得多。USB外壳如果是金属的，会对天线形成大半个包围的屏蔽盒，信号性能会严重劣化。所以做产品设计时，要么选塑料外壳，要么把天线部分延伸到壳体外面。

另外就是在PCB上预留测试点。射频测试点可以引出到板边，生产的时候用探针接触测功率；电源测试点、地测试点也要预留，方便固件烧录和调试。这些小细节看似不起眼，后期量产时能帮你省大量时间。

外壳的开孔位置、指示灯的开窗方式也会影响用户体验。最好不要把LED直射人眼，稍微内凹或者用导光柱柔化一下，这些小地方决定了一个硬件东西是不是有产品感。

4. 协议栈集成实战：把Dongle跑起来才是重头戏

硬件做好之后，最核心的一环就是把协议栈接进来，让Dongle真正工作在对应系统上。我先从HCI层最基础的交互讲起，然后分别说Linux、Windows和嵌入式下的接入方式。

4.1 HCI命令的底层交互逻辑

HCI传输层定义了几种包类型，最常见的是命令包、事件包和数据包。主机发命令给控制器，控制器执行完回一个命令完成事件或者命令状态事件；如果控制器有主动通知的事情，比如连接断开、扫描发现设备，就发异步事件给主机。ACL和SCO数据包则是走数据的通道，是双向传输的。

一个标准的HCI命令包大概长这样：先是2字节的OpCode，它由OpCode Group Field和OpCode Command Field组成，比如HCI_Reset的OpCode是0x0C03，其中0x0C00是OGC字段里的“控制器与基带命令”；然后是1字节的参数总长度，紧接着是命令参数。这个格式看起来简单，但不同的控制器对命令的容错度不一样，有的命令参数传错了会直接返回错误码，有的干脆卡死，需要你手动复位。

我自己调试过程中最喜欢用的第一步永远是HCI_Reset。无论你拿到一颗新芯片还是怀疑控制器状态异常，先发HCI_Reset把控制器恢复到已知状态，再通过HCI_Read_BD_ADDR读取蓝牙地址，通过HCI_Read_Local_Version_Information读取芯片版本，基本就能确认链路是通的。这个习惯帮我排查过大量“芯片好像没工作”的问题，其实很多只是上电后没有正确完成初始化。

4.2 Linux下用BlueZ把Dongle领进门

Linux平台的蓝牙协议栈几乎就是BlueZ的代名词。把Dongle插上之后，USB设备会被btusb驱动识别，然后被BlueZ接管。通常你会看到这些设备节点出现：

$ lsusb Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) $ dmesg | grep Bluetooth Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b Bluetooth: hci0: Boot loaded Bluetooth: hci0: Firmware loaded

如果设备没有自动被正确引导，可以使用bluetoothctl来管理设备。比如连接一个经典蓝牙耳机，我用的是这种操作流：

$ bluetoothctl power on agent on scan on pair 11:22:33:44:55:66 trust 11:22:33:44:55:66 connect 11:22:33:44:55:66

平时调试HCI层的小工具，hcitool是最直接的一个。查看控制器状态用sudo hcitool dev，扫描周围设备用sudo hcitool scan，读RSSI用sudo hcitool rssi <bdaddr>。更底层的HCI日志，用btmon抓取，它会把主机和控制器之间的所有HCI命令、事件、数据包都打出来，定位问题神器。

如果Dongle是通过UART HCI接入Linux，那比USB稍麻烦一点，需要确定串口设备号和波特率。老一点的流程是用hciattach把串口绑定成蓝牙接口：

sudo hciattach /dev/ttyS0 any 115200 flow sudo hciconfig hci0 up

当然，现在很多UART蓝牙方案也支持通过btusb类似的驱动加载固件，这取决于控制器厂商有没有内核驱动模块。

4.3 Windows下的驱动与兼容性处理

Windows这边的体验相对“黑盒”一些，因为微软有一套自己的蓝牙驱动栈，很多时候厂商驱动和系统内置驱动还会有冲突。我做过几版Dongle，在Windows上遇到最多的问题集中在两类：一是驱动装不上或装了没反应，二是设备在设备管理器里删不掉、重置不掉。

先说第一种。很多USB HCI Dongle在首次插入时会显示为“未知USB设备”或者“USB输入设备”，这是因为系统还没有给它匹配到蓝牙驱动。解决方式是先确认USB枚举是否成功，看设备管理器里有没有带黄色感叹号的设备，然后右键更新驱动，手动指定到厂商驱动的inf文件，或者下载对应芯片的驱动安装包。热词里那个“win7插入蓝牙后没反应”就非常典型，很多时候是因为Win7系统没有集成新版蓝牙栈，需要先打上微软补丁，再装芯片厂商驱动。

再说第二种，“win10蓝牙删除设备删不掉”这个我在支持群里被问到过无数次。这种情况一般是蓝牙设备的配对记录和系统缓存没有同步清除，或者驱动层面有残留。我在实际操作中比较有效的一套办法是：先到“设置-设备-蓝牙和其他设备”里把设备移除，再到设备管理器里把蓝牙适配器卸载（勾选删除驱动程序软件），然后重启电脑，重新扫描配对。如果还不行，可以借助Powershell移除蓝牙设备记录：

Get-PnpDevice -Class Bluetooth | Remove-PnpDevice -ErrorAction SilentlyContinue

跑完这条之后重启，再重新安装驱动。要注意的是，这个命令会清掉所有蓝牙设备的配对记录，执行前务必考虑清楚。

4.4 嵌入式与Android下的接入思路

嵌入式平台接入HCI Dongle，最经典的就是UART HCI。主控芯片通过串口和蓝牙控制器相连，然后在主控这边移植或者使用开源协议栈，比如Zephyr的蓝牙协议栈、NimBLE、或者Linux内核里的BlueZ。接入的关键在于底层HCI传输接口的适配，你需要实现一个从UART读取HCI数据并解析成包的功能，然后把数据喂给协议栈。可以把这个过程理解为“给协议栈提供串口搬运工”。

Android系统从历史上看，早期使用BlueZ，后来换成了自己的Fluoride协议栈，最后又逐渐迁徙到Gabeldorsche（虽然落地速度比较慢）。如果要在Android上使用UART HCI的设备，通常会在init阶段由bluetooth HAL层加载固件，再通过vendor命令配置波特率和控制器参数。最常见的调试方法就是抓HCI日志，用adb bugreport或者bt_stack.conf打开HCI snoop log，然后导出来看。

对于大部分想快速验证Dongle硬件是否正常的嵌入式朋友，我还是建议先在Linux主机上跑通再移植，因为Linux下调试工具齐全，日志直观。等确认控制器没有硬件问题、HCI链路稳定，再去做嵌入式集成，能少踩很多暗坑。

5. 调试工具链与实测记录分享

协议栈集成做完，重要的就是调试和实测了。这一章我分享一些我常用的工具和一组真实测试数据，给后来者一个参照系。

5.1 必备的调试工具

我用得最多的是这几个：

第一，Linux下的btmon。它能记录所有HCI层的事件和命令，而且带时间戳，非常方便分析控制器的状态变化。比如你发现连接总是断开，通过btmon可以很清楚地看到是谁发起了断连，是主机侧超时还是控制器上报了错误，这比看上层应用日志要准确得多。

第二，hcidump或者新版BlueZ里的btmon。经典蓝牙时代hcidump很好用，但在BLE时代功能慢慢跟不上了，我大部分时间转向了btmon加Wireshark的组合。不过hcidump在分析传统配对流程时还是有不小的价值。

第三，逻辑分析仪和示波器。做UART HCI调试时，逻辑分析仪是必备的，尤其分析HCI命令超时问题，直接抓UART波形看有没有数据发出、有没有数据返回。示波器主要用来看电源纹波和信号质量，排查射频干扰导致的问题。

第四，厂商的专用调试工具。CSR就有BlueSuite、BlueTest，Realtek有BTtool，Nordic有nRF Connect系列，这些工具能让你操作到HCI之上的私有命令，对分析控制器行为很有帮助。如果碰到BTool也解决不了的问题，那大概率就得回到HCI层去看了。

5.2 实测数据：一次完整Dongle测试是怎么做的

我以自己那款基于nRF52840的USB HCI Dongle为例，给出一组实测数据，完整的测试流程大家可以照抄。

• 硬件：nRF52840 USB Dongle，PCB天线，板载LDO供电。
• 软件：Linux Ubuntu 22.04自带的btusb + BlueZ 5.65；Windows 11系统自带蓝牙栈。
• 测试项目一是经典蓝牙SPP传输速率。两台设备用RFCOMM连接，用一段随机数据持续传输，实测平均吞吐大约在80-100KB/s左右，这个数字符合经典蓝牙SPP的典型带宽。如果你测出来只有几KB/s，基本可以怀疑协议栈配置、流控或者缓冲区设置有问题。
• 测试项目二是BLE连接稳定性。在室内环境，手机连接Dongle，连接间隔设置为7.5ms，持续播放数据30分钟，没有出现断开。如果频繁断连，就要检查天线的回波损耗、连接参数是否被手机拒绝，以及USB的电源休眠策略。
• 测试项目三是空旷环境下的广播扫描距离。用手机和Dongle互扫，手机能扫到Dongle广播的最大距离约为40米左右，Dongle扫手机约35米，差距主要来自手机发射功率和天线效率差异。这个成绩不算顶尖，但对一个PCB天线的Dongle来说已经够用了。

5.3 和HC-05这类经典串口模块的对比

很多人搜索“hc05蓝牙模块连接不上”这类问题，我在这里正好做一次对比。HC-05是把串口转SPP Profile的完整方案，你用AT指令配置好之后，它自己会做配对、连接、透传。而HCI Dongle本身不实现这些功能，必须配合协议栈使用。

我自己现在的习惯是：只是把两个单片机之间的有线串口换成无线，图省事就选HC-05这类模块；但如果要做的是把蓝牙接进一个完整的系统，比如Linux设备或者自研嵌入式主板，那就一定用HCI Dongle方案，后期维护升级时你就知道它的价值了。

6. 常见问题排查实录：从现象到根因

最后这部分是面向实战的排查记录。我把高频问题、排查思路和根因分析整理成一个实战手册，任何一条都有可能是你接Dongle时会遇到的。

6.1 插入电脑后完全没有反应

现象：Dongle插上USB口，没有新设备出现，设备管理器里连未知设备都没有。

排查思路是先用排除法锁定问题层级。第一看供电和枚举，用USB电流计或者示波器测VBUS和D+/D-波形，确认Dongle有没有上报USB设备描述符。如果D+和D-完全没有差分信号，大概率是芯片没工作或者USB路径断线。第二看电源和时钟，量芯片的VCore有没有起来，量晶振有没有起振。很多时候就是晶振虚焊或者电容值不对，导致芯片根本没有进入工作模式。第三看芯片固件，有些芯片需要先烧录Bootloader和固件才能跑起来，裸芯片插上当然没反应。

我在自己的板子上就遇到过：贴片完一片板子插上电脑没任何反应，用示波器量晶振发现没振荡，后来发现是晶振负载电容选得和晶振不匹配，起振条件不足。把那两颗对应负载电容调整之后，振荡起来，设备就正常枚举了。

6.2 连接不稳定、频繁断连

现象：Dongle能扫描、能配对，但连接建立后过一会儿就断，或者距离稍远一点就掉线。

这种问题优先级最高的怀疑对象永远是射频链路。先看天线区域有没有杂散器件、PCB天线下方有没有铺铜，匹配电路电容电感值对不对。再检查供电，尤其是射频发射瞬间的电流拉载，如果LDO余量不足，发射时电压跌落，控制器可能直接就复位了，表现就是莫名其妙的断连。

还有一种很不显眼的原因，就是USB选择性挂起。Windows默认可能会把HCI设备所在的USB端口挂起以省电，导致Dongle在电脑空闲一段时间后就“失踪”。解决方式是到设备管理器的USB Root Hub属性里，把“允许计算机关闭此设备以节约电源”的勾去掉。

6.3 与手机连不上或者配对总是失败

现象：手机能搜到Dongle，但配对时失败，或者配完对下次又连不上。

这类问题先看配对模式。如果你的Dongle需要输入PIN码，主机侧必须配置正确的IO能力。很多低功耗蓝牙设备默认是Just Works配对，不需要输密码，但传统蓝牙往往要。需要检查Host侧配置的SSP（Secure Simple Pairing）模式和IO能力是否匹配。

另外，配对记录残留是另一个高频元凶。Windows和手机端都只能存有限个配对设备，如果曾经用同一个蓝牙地址配过对，现在换了新的Dongle但BD_ADDR没变，两边的旧密钥会对不上。清理方法通常是把两边设备都忘记掉，重开配对流程。如果还不行，可以把Dongle的BD_ADDR改掉，绕过密钥冲突。

还有一类是控制器固件bug，表现为特定的手机连接失败，但另一台手机正常。这时候我一般开btmon抓HCI日志，看是哪一步失败，是被Security Mode拒绝还是在Encryption阶段超时。定位到具体错误码后，要么升级固件，要么在主机侧调整安全策略。

调试到最后你会发现，HCI Dongle真正难的并不是哪一块具体的电路，而是你得能同时从硬件现象、系统日志、协议交互三个层面交叉判断问题到底是出在物理层、驱动层还是上层策略。这种综合能力，正是做系统集成的价值所在。我自己做这类项目最大的心得就是：先固件、后硬件、再系统，一步步把边界划清楚，问题就永远不会扎堆出现。等你手里有一块完全由你自己掌控的HCI Dongle，再回头去调那些“连不上”“断连”的老大难，你会发现自己看蓝牙问题的视角完全不一样了。