ESP32 BLE Client仅读取8个特征值字符的技术求助

核心原因 #

你遇到的问题本质是没有正确处理BLE数据的字节流长度，错误修改uint8_t*为uint16_t*会引发字节对齐、内存越界问题，反而适得其反。BLE特征值的传输是基于字节的，uint8_t*是正确的数据类型。

解决方案 #

1. 修复通知回调的处理逻辑

在notifyCallback中，必须利用传入的length参数遍历所有字节，而不是固定只处理前4个字节（对应8个十六进制字符）。示例代码：

void notifyCallback(BLERemoteCharacteristic* pBLERemoteCharacteristic, uint8_t* pData, size_t length, bool isNotify) {
  Serial.print("收到特征值（");
  Serial.print(length);
  Serial.println("字节）：");
  // 遍历所有字节，转成十六进制字符串输出
  for (size_t i = 0; i < length; i++) {
    Serial.printf("%02X", pData[i]);
  }
  Serial.println();
}

这里的关键是依赖length判断实际收到的字节数，如果特征值是8字节（对应16个十六进制字符），length会返回8，遍历后就能输出完整的16位十六进制字符串。

2. 主动读取时使用readRawData

如果是主动读取特征值而非依赖通知，不要使用readUInt32()这类固定长度的读取方法，改用readRawData()获取完整字节流：

// 假设已获取到目标BLERemoteCharacteristic对象pRemoteChar
uint8_t rawBuffer[8]; // 根据特征值实际长度定义，可先通过getLength()获取
size_t readLen = pRemoteChar->readRawData(rawBuffer, sizeof(rawBuffer));

if (readLen == sizeof(rawBuffer)) {
  Serial.print("完整特征值：");
  for (size_t i = 0; i < readLen; i++) {
    Serial.printf("%02X", rawBuffer[i]);
  }
  Serial.println();
} else {
  Serial.printf("读取不完整，仅获取%d字节\n", readLen);
}

可以先调用pRemoteChar->getLength()获取特征的官方定义长度，再动态分配内存或定义对应大小的数组，避免硬编码长度。

3. 避免修改uint8_t*类型的原因

BLE协议以字节为单位传输数据，uint8_t*是逐字节访问的正确类型。改为uint16_t*后：

• 会将两个字节合并为一个16位整数，打乱原始字节顺序（受端序影响）
• 内存访问会出现越界：如果实际收到8字节，uint16_t数组仅能容纳4个元素，超出后会触发非法内存访问，导致程序崩溃或乱码

额外验证步骤 #

• 确认连接的特征UUID与nRF Connect中看到的目标特征完全一致，避免误连到其他短长度特征
• 在nRF Connect中查看目标特征的Value Length，确认确实为8字节（对应16个十六进制字符）
• 检查registerForNotify调用是否正确传入了回调函数，没有遗漏参数

内容的提问来源于stack exchange，提问作者Christoff van Zyl