[参考译文] CC1312R：非信标模式关联序列

大家好、Kevin

对于您描述的第一种情况、答案是肯定的、15.4 stack 通过保留已成功配置的器件列表来解决此问题、因此基本上、只要此传感器恢复在线状态、收集器就会发送配置请求消息

对于第二种情况、您可以实施自己的身份验证方法、例如、如果您在从设备列表中删除特定时间后从未收到来自传感器的响应、则加入传感器的质询响应会超时。

appsrv_processRemoveDeviceReq 发送一个取消关联请求，该请求作为间接消息排队。 这意味着收集器将等待传感器发送数据请求以轮询消息、否则收集器不会通过无线方式发送此数据包。
此外，在调用 appsrv_processRemoveDeviceReq()之前，您可能需要调用 Cllc_removeDevice 以确保从关联的设备表中删除此设备。

在为传感器1调用 appsrv_processRemoveDeviceReq()后，您可能会在向传感器2发送消息时遇到问题的原因可能是 TX 缓冲区已满。 解决此问题的一种方法是增加 TX 缓冲区大小、该大小由 mac_cfg.c 文件中的 MAC_CFG_TX_MAX 和 MAC_CFG_TX_DATA_MAX 定义

请注意、如果更改缓冲区大小、则必须重新编译并刷写协处理器

Hecter_r、您好！

感谢您的解释。
我确实调用 Cllc_removeDevice()来将传感器与 appsrv_processRemoveDeviceReq()一同删除，但结果不同。
案例1：
传感器1成功与收集器关联、这意味着收集器接收到 commStatusInd。 之后，主收集器调用 appsrv_processRemoveDeviceReq()和 Cllc_removeDevice()时没有问题，传感器1是否发送数据请求轮询消息。

案例2：
传感器1尝试但未能与收集器关联、这意味着收集器接收到 deviceJoinedInd 和 deviceAssocInd、但没有 commStatusInd。 之后，如果我调用 appsrv_processRemoveDeviceReq()和 Cllc_removeDevice()来移除该传感器，则如上所述，到传感器2的数据流量会被阻塞。

在您增大 MAC_CFG_TX_MAX 的大小后、情况2是否仍然发生？

此外、您能否为案例2提供监听器日志、以便我尝试重现问题

我进行了以下测试：

1.将 MAC_CFG_TX_DATA_MAX 从2增加到4 ->相同的错误。

2.将 MAC_CFG_TX_MAX 从5增加到10 -->正常工作。

请参阅随附的日志和屏幕截图：

从数据包1到19、主机收集器每5秒向传感器1 (0x0001)发送一次应用保持活动状态。

在第23号数据包中、传感器2 (00：12：4b：00：18：9a：E3：bb)尝试关联、但由于我的中断、如上所述、失败。

2秒后、收集器尝试向传感器2发送取消关联、并将其从关联表中删除。

之后、收集器无法向传感器1发送任何数据包。

在第29个数据包中、传感器1发送取消关联到收集器、因为应用程序保持活动超时、然后尝试再次关联。

e2e.ti.com/.../subg_5F00_cap.zip

您好！

从我可以看到收集器中的 TX 缓冲区已满、因此当您尝试从收集器向传感器2发送数据时、缓冲区已满、数据甚至未放入缓冲区。 您是否检查了在向 sensor2发送数据时 sendMsg API 的返回状态是什么？ 此状态应告诉您缓冲区是否已满。 此外、由于 sensor1不再轮询、因此集合仍将在缓冲区中保留 sensor1的消息、直到发生由 INDIRECT 持久性时间定义的超时

Hector、您好！

sendMsg API 的返回状态始终为成功。

实际上、从收集器发送到传感器1的数据有效载荷每5秒仅为1个字节。

我认为收集器尝试向未成功完成关联过程的传感器发送断开关联数据包可能会导致此问题。

您能否重现此问题或确定是否符合我的猜测？

谢谢。

您好！

我目前正在尝试重现此问题、当我有更新时、我将通知您。