XBEE 3 Zigbee 3.0与mbed LPC1768 SPI通信时浮点数据异常求助

我正在搭建微控制器mbed LPC1768与XBEE 3 Zigbee 3.0的SPI连接，目标是实现mbed与电脑间的无线浮点数据传输。已完成部署，通过另一台连接电脑的XBEE设备以单播方式接收数据，整体运行正常。为测试效果，我发送正弦波数据并在Simulink中绘图，结果显示信号存在多处明显错误，且错误值始终出现在相同数据位置。后续通过XCTU读取消息发现，仅特定数据的接收报文内容被篡改。

发送的mbed消息为：

uint8_t Message[23] {0x7E, 0x0, 0x13, 0x10, 0x1, 0x0, 0x13, 0xA2, 0x0, 0x41, 0xC1, 0x80, 0xD5, 0xFF, 0xFE, 0x0, 0x0, 0xBB, 0xBE, 0xDD, 0x7D, 0x3F};

其中0xBB是4个浮点字节的头字节（校验和在程序中后续计算）。但接收的数据帧字段中突然出现了5个字节（最后一个为校验和），其他数据则能正确以4个数据字节接收。疑问：为何仅特定数据的报文内容会被修改？

• XBEE API帧转义规则触发：XBEE的API帧格式规定，当负载数据包含帧起始符0x7E、转义符0x7D、XON0x11、XOFF0x13这些特殊字节时，发送端XBEE会自动对该字节进行转义操作——在其前插入0x7D，并将原字节异或0x20。如果你的浮点数据中恰好包含这类特殊字节（比如你发送的负载里的0x7D），转义后实际发送的帧长度会比原定义多1字节。若接收端或你的程序未正确处理转义逻辑，就会把转义后的额外字节当成负载数据，出现“接收报文多1字节”的情况，且只有包含特殊字节的报文才会触发该问题，这正好匹配你“仅特定数据被篡改”的现象。

• 校验和计算逻辑错误：你提到校验和在程序后续计算，若计算时未考虑转义后的实际发送字节，仍基于原Message数组的内容计算，会导致校验和不匹配。接收端XBEE在校验失败后，可能错误解析帧结构，比如把校验和字段当成负载的一部分，或者错误扩展负载长度，进而出现异常的字节数量。

• SPI通信配置不匹配：排查mbed与XBEE的SPI参数是否完全一致（时钟极性CPOL、时钟相位CPHA、波特率、数据位宽）。若特定数据传输时触发了SPI的帧同步错误，也可能导致字节误读，但这类问题通常伴随更多随机错误，优先级低于前两点。

内容的提问来源于stack exchange，提问作者Rekmix