发送过多串行数据时，Digis XBee 系列 2 固件冻结/崩溃。可靠性很差

Posted 2023-02-19

【中文标题】发送过多串行数据时，Digis XBee 系列 2 固件冻结/崩溃。可靠性很差

【英文标题】：Digis XBee Series 2 Firmware freezes/crashes when sending too much serial data. Reliability is bad

【发布时间】：2014-08-17 13:02:21

【问题描述】：

症状： 我这里有几个 XBee 24-ZB series 2，它们作为协调器连接在 PC 上，作为路由器连接在终端设备 (AVR) 上（无睡眠）。

当发送大量数据时，路由器/终端设备 XBee 可能会突然冻结 DIN 线路。它仍然可以通过无线电通信，它仍然可以将接收到的数据串行传输到微控制器 (DOUT)，但忽略 DIN。

XBee 在transparent 模式下运行，并且无论您多久尝试一次，它都会忽略 AT 命令（带有保护时间的+++）。我非常确定波形是干净的，用滤波电容读取 VCC 是稳定的，阅读手册和数据表。

唯一的解决方案是重置 XBee 或重启 XBee 设备。

波特率： 我尝试了 111111 和 250000。它们非常适合 XBee（0% 误差）和同样在 16 MHz 晶体上运行的 AVR。在 XBee 工作期间，它可以传输大量数据而不会发生任何损坏，并且微控制器的复位不会改变任何事情。

【问题讨论】：

供您参考：类似问题已发布到 Digi 支持论坛，xbee-series-2-module-enter-undefined-state

【参考方案1】：

这个问题似乎永远不会消失，这是一种耻辱，因为正如人们所指出的那样，这是一个根本性的缺陷。

我试图通过流量控制来解决这个问题，这似乎有所帮助，但路由器固件 XBee 设备似乎仍然会崩溃。我猜它同时接收要路由的数据包...

我的完整和最终解决方案是让连接的设备控制 XBee 的重置引脚，因此当它崩溃时，设备可以在超时后重置它。这不是一个很好的解决方案，但它是 100% 有效的。

【参考方案2】：

这件事的原因似乎是（已知！）固件错误。

XBee 具有通常在微控制器上不使用的硬件流控制；它是额外的线路、路由、编程，在大多数情况下并不那么重要。 XBee 有一个用于串行输入的接收缓冲区，可以填满。它应该忽略其他数据；如果您发送的内容超过了它可以通过无线发送的内容，它将开始丢失字节。

如果在接收缓冲区满后继续发送数据，它将进入非法状态，这绝对是一个错误，恕我直言。如果您推送数据一段时间，它将无限期地停止获取数据，直到硬重置。

注意：它也不再发送任何无线电数据，因此即使缓冲区已满，它也不会继续使用它。我试图从 digi 支持部门获得确认，但如果不支付 99 美元，他们将不会回应这一事实（一个问题 = 99 美元）。我不会花 100 美元来讨论他们固件中的错误。他们应该修复它！

解决方案是要么实施硬件流控制，要么绝对确保您不会发送太多数据。无线电吞吐量为 5 到 39 kbit/s，具体取决于具体情况，因此您需要包含 ACK 的 API 模式或等待无线电合作伙伴设备的响应（自己的 ACK 层）。

我用两个不同的原型和三个全新的 XBee 模块 (XB24-ZB) 验证了这一事实。

如果有人对此主题有更多信息，我将不胜感激。

【讨论】：

我在使用 XBee Pro 868 时遇到了同样的错误。我的解决方案启用并检查 XBee 上的 CTS 引脚。它被正确地断言和取消断言，但是在大约 10 分钟的工作和发送了数百千字节的数据之后，CTS 保持高电平（取消断言）并且 XBee 根本不通过 UART 响应并且不切换到命令模式。 Assoc LED 闪烁。

是的，我还启用了硬件流控制，但 xbee 的可靠性一直是我的问题。他们的固件真的很糟糕。他们将可靠性宣传为其主要功能之一，同时可靠性一直是我对 xbees 的第一大问题。 （专业版和普通版）对于无线电控制器来说，这是一件非常糟糕的事情。我还遇到了许多其他必须解决的严重问题。应该在 pre alpha 中修复的东西。

【参考方案3】：

有几种可能的解决方案：

将波特率降低到不会溢出 XBee 模块的串行缓冲区的程度。 实现硬件流控制，并在 XBee 模块取消断言 CTS（告诉您其缓冲区已满）时停止发送数据。 等待另一端收到数据包的确认。 切换到 API 模式并等待每个发送帧的 Tx 状态帧。

我同意这是 XBee 固件中的一个错误，如果您在取消断言 CTS 后继续发送字节，它不应该锁定。

但我也认为，即使 XBee 没有锁定，您仍然会遇到问题。您真的希望它开始随机丢弃数据吗？

适当的设计会同时使用 CTS 和 RTS 信号，以避免主机和 XBee 模块之间丢失任何数据。主机在其缓冲区接近满时取消断言 RTS，并且在 XBee 模块取消断言 CTS 时不发送数据。

【讨论】：

确实是这样。然而，这是一个非常可靠的无线电设备中的严重错误。我敢肯定，很多人都为此发了白发，因为很难相信这样一个原始的showstopper bug 是最新固件的一部分。

我的设计确实使用了 XBee Pro 868 上的 CTS 信号，但问题仍然存在。 CTS 被正确断言和取消断言，但在大约 10 分钟的工作和大约数百 KB 的数据发送后，CTS 保持高电平（取消断言）并且 XBee 根本不通过 UART 响应并且不会切换到命令模式。 Assoc LED 闪烁。 UART 数据速率为 115200，用 ATFT 更改缓冲区填充阈值似乎不会产生任何差异。

我怀疑这些方面存在问题：XBee 模块的接收缓冲区已满，它取消断言 CTS。主机看到 CTS 无效并停止发送字节，但仍有一个字节在传输中，并且 UART 中还有一个或多个字节等待发送。 XBee 模块可能处于在取消断言 CTS 后接收 3 个字节导致锁定循环缓冲区的状态。尽管缓冲区已满，但从其中提取字节的代码以某种方式将其视为空的。它可能是多个设备通用的代码。

@tomlogic 从理论上讲，XBee 的接收缓冲区中的可用空间量阈值，低于该阈值 CTS 被取消断言由 ATFT 命令调节。 Pro 868 的默认值为 0xA0，我尝试将其减小到 0x80 并提高到最大值 0x13F，但在这两种情况下都没有观察到变化。