当前位置：首页 > news >正文

蓝牙开发那些事儿12——（记一颗BLE芯片BringUp折腾过程）

news 来源：原创 2025/8/17 20:29:07

1.背景

蓝牙这个系列已经很久很久没有更新了，感慨良多。

现在写这篇文章主要是BringUp一颗蓝牙芯片的过程中遇到了一些奇怪的问题，想了一些办法，一一克服了，看看对其他做蓝牙的同学有没有启发。

同时也安利一个叫做HACKRF的设备。借助于目前软件定义无线电的飞速发展，在定位射频类问题的时候，真的已经比以前什么手段都没有的时候快多了也方便多了，一个HACKRF的设备大概也就700多元，最后解决了困扰我数周的问题。

目前这家公司是做BLE芯片的，用的CEVA的蓝牙5.2的IP核，在我来这家公司之前，蓝牙的协议栈和软件部分由深圳团队负责，但是大半年时间了，一直也没有把蓝牙功能跑起来。

因为一些历史的原因，芯片在FPGA阶段并没有经过严格的验证，资料也极度缺乏，蓝牙协议栈的代码最后到我手上也是几经坎坷，没办法，这就是内耗。

拿到代码后，先移植到芯片的sdk上跑起来，（之前的软件团队居然连这一步移植协议栈的工作都没做好，也是醉了），第一步任务是先跑通蓝牙协议栈，结果折腾了很久，连最基本的BLE的广播包能不能发出来；从软件层面上看应该已经发出来了，但是sniffer却死活收不到。

2.调试过程

既然从软件层面上看adv包已经发出来了，但是sniffer收不到，那么要么是基带有问题要么是RF有问题。基带是CEVA的核，虽然之前验得不充分，但是出问题的概率较小（我也只能姑且这么认为），而RF模块是自己另外加的，所以有可能问题出在RF这儿。

于是借了一个手持式的频谱仪，发现在广播包的频段上（蓝牙协议规定的BLE三个广播channel是37、38、39，对应频率为2402Mhz，2426Mhz，2480Mhz），是时不时有信号发出来的。

一开始猜测的是是不是RF的功率太小了，改动PA部分的电路等等，后来发现没啥效果（其实功率关系不大，后来调通以后，哪怕不接天线，近距离的情况下信号也挺强的），从频谱仪上看，不改动电路的情况下，发送功率可以到接近0dbm左右的。

2.1 DTM

由于之前据说这颗芯片拿回来后是跑通过DTM测试的（DTM(Direct Test Mode)直接测试模式,是SIG联盟在蓝牙核心规范中制定的一种用于蓝牙射频性能测试的模式。），因为dtm测试最简单，只需要配一些寄存器，让芯片进入test mode，就可以进行tx、rx的测试，配合一台测试仪（例如8852等等），看看频谱、数据等等对不对就可以初步判定这颗ble芯片的RF是否正常。

问题是，当我向之前做DTM测试的同事要求拿DTM测试报告的时候，居然得到了“没有”的回答。

于是dtm测试在我这里也打上了问号，我必须重新来做一下DTM测试了。

DTM测试是需要8852这样的设备的，由于无锡这边没有，只能先借了一台频谱仪，频谱仪不能解析payload，但是大概看一下频谱，还是可以的。

DTM的代码也费了一些周折拿到了，跑起来后发现不太稳定，修复后，得到了如下的频谱图

一开始看到这里的结果是大喜的，因为蓝牙规定频偏是150khz以内，这里偏了178khz，问题就大了。和负责rf的工程师沟通后，修改了一些寄存器后，频偏修复了，当时为了看这个频偏的问题，怕手持式频谱仪不靠谱，还去借了一个高级的频谱仪：

这次看上去频偏正常了，赶紧再去跑跑正常的协议栈看看，结果是令人沮丧的，广播包依然没有发出来，问题依旧。

2.2 MT8852

现在问题又回到了原点，RF的频谱是正常的，不能证明说RF就没问题。频谱只能证明说载波的频点是对的，并不能说调制解调没有问题，BLE的调制方式GFSK（不绝对，蓝牙5.2支持1M、2M和coded三种调制方式，我们现在调试最基本的legacy adv包，是属于1M phy，GFSK的调制）是否有问题，还需要能看到payload才行，而频谱仪是无法解析payload的。

于是我们搞到了专业的设备MT8852。之前并不了解这个设备是否可以解析payload，为了验证这个问题，我得先试试，先找了上一代芯片（上一代芯片是可以正常发出广播包的）。

先试了一下上一代芯片的DTM测试，这个时候，设备不需要做什么设置，就可以解析payload，如下图所示

那么广播包是否可以解析呢：

一开始我以为是不可以的，因为抓到的广播包是下图这种：

但是后来我发现是可以的，只要设置对了access code的话，如下图（因为test mode和广播包的access code是不同的），下图中的packet contents是通过点击"show packet details"按钮打开的，但是要注意，这个show packet details要提前打开才可以解析，应该是软件bug。另外，从这个payload上看，应该是蓝牙地址的第一个字节01被吃掉了，最后又多了一个00，这个应该是解析错误，从上面的波形上看，是对的，有01 的。

然后赶紧试下我们现在的芯片，先试试dtm，抓到了：

再试试广播包，抓到这个，很奇怪，是全黑的，无法解析，肉眼解析的话，从access code 也完全看不出正常广播包的access code ——0x8e89bed6。

当时我其实没想明白这个事儿，总以为是自己对8852不太了解造成的，直到下一节的实验过后......

2.3 HACKRF

从频谱仪上看，在广播的频段（2402Mhz、2426Mhz、2480Mhz）有数据发出，只是无法解析其中的数据是否符合蓝牙协议。

市面上的sniffer，通常只能解读符合蓝牙协议的数据包，如果不符合蓝牙协议，比如说收到一个GFSK的数据包，解析后发现其中的preamble是错的，或者access code是错的，或者crc是错的，都会直接丢掉，我们就无法分析到底发生了什么。

最好有一款设备，只做GFSK解调，解出来的数据，不管黑猫白猫，统统给我们显示出来，由我们来分析问题到底出在哪里。

这样的设备前几年还没有，现在还真有了。

就是一款叫做HackRF one的设备，这个设备是软件定义无线电的产品。

‌HackRF‌是一款由Great Scott Gadgets公司推出的开源软件无线电（SDR）平台。它具有广泛的频率覆盖范围，从1 MHz到6 GHz，支持大部分常见的无线通信频段。HackRF采用软件定义无线电技术，提供了自定义和控制无线信号处理的能力，包括接收、发送、解码和干扰等功能‌12。

主要功能和应用场景

‌接收和解码无线信号‌：HackRF可以接收并解码各种无线信号，如无线电广播、无线电通信、无线电定位等。用户可以使用HackRF来监听和分析无线信号，了解无线通信的工作原理‌1。

‌发送和模拟无线信号‌：HackRF可以生成和发送各种无线信号，用于无线通信实验、无线信号干扰测试等。用户可以通过HackRF进行无线通信实验和信号干扰测试‌1。

‌破解和分析无线协议‌：HackRF可以用于破解和分析各种无线协议，如无线门禁系统、汽车遥控器、无线键盘鼠标等。通过分析无线协议的加密算法和通信流程，可以进行安全评估和漏洞分析‌1。

‌定位和跟踪无线信号‌：HackRF可以用于定位和跟踪无线信号的发射源，适用于无线摄像头、无线麦克风等的定位和监控‌1。

技术规格和硬件配置

HackRF One是一款基于FPGA和ARM的软件定义无线电外设，具有以下主要技术规格：

‌工作频率‌：1 MHz至6 GHz

‌采样速率‌：每秒高达2000万次

‌采样精度‌：8位正交采样（8-bit I 和 8-bit Q）

‌兼容性‌：与GNU RadioSDR#

‌控制接口‌：支持USBSD卡接口LPC_JTAG接口I2SSPII2CUART协议接口等‌3。

从原理上看，可以用来嗅探蓝牙数据包，因为Hackrf支持的软件比较多，比如像Gnuradio这样的图形化的开源软件，也可以用来进行编程。

hackrf设备如下图：

将hackrf作为蓝牙嗅探器的代码网上还挺多的，最后我找了一个写得比较好的：

GitHub - JiaoXianjun/BTLE: Bluetooth Low Energy (BLE) packet sniffer and transmitter for both standard and non standard (raw bit) based on Software Defined Radio (SDR).

抓到了

比较下我们的数据和其他数据，可以看到，我们的数据看着反而是正常的，人家的数据看着倒像是错的，联想到之前8852测试的结果，我一下子想明白了，蓝牙收发包过程，有个scramble又叫whitening的工序，目的是避免长时间全零的数据影响射频特性，我们的芯片，应该是没做这个scramble。为了验证这个想法，就很简单了，hackrf是可以编程的，对收到的raw data进行dewhitening，这一次，人家的数据是对的，而我们的数据是不对的。

于是，到协议栈的代码里找到相关寄存器，发现果然是代码问题，谁把我们芯片的scramble关掉了。

如下图：

注意红框说明，为了测试的目的，关闭了whitening，这个东西，本来应该是dtm测试的时候关掉，而在正常跑协议的时候打开，现在居然改到了全局，显然就是不对了。

坑，又填了一个。

1.背景

2.调试过程

2.1 DTM

2.2 MT8852

2.3 HACKRF

相关文章：