[参考译文] CC2538：ZNP -为什么所有重试？

好的，明天我会将该理论付诸测试，向其发送一些消息，然后生成另一个日志。

我已向ZStack添加了通知，以便我的应用程序收到加入网络的任何设备，详细信息或无详细信息的通知。

我非常怀疑ZNP代码中存在竞争条件，因为有时它会在我发出指令后几分钟内传输许可加入，此外(根据Ubiqua)它会在几分钟后发送多个虚假许可加入。 有时我们不得不冷启动ZNP。 这种对地雷的怀疑也与上述轨迹中观察到的延迟重试模式相一致。

e2e.ti.com/.../TransportKeyRetries.zip

Ubiqua踪迹^

链接密钥为69:90:2e:ec:dd:6d:99:6d:aa:0d:be:25:31:5b:54:7b

我们正在查看链路密钥(序列号197)的重试次数切换，如上图所示。  终端设备成功加入。


我向Mac-TX添加了一些跟踪，以下条目对应于链接密钥重试次数：

Mac_TXS：TS 89.3208万 CSMA 1 FrmeTyp 1 ReTx 0 Len 71：FC 8861 SN 197 PAN AE3 nAddr d80f
Mac_TXS：TS 89.3235万 CSMA 1 FrmeTyp 1 ReTx 1 Len 71：FC 8861 SN 197 PAN AE3 nAddr d80f
Mac_TXS：TS 89.3244万 CSMA 1 FrmeTyp 1 ReTx 1 Len 71：FC 8861 SN 197 PAN AE3 nAddr d80f
Mac_TXS：TS 89.3263万 CSMA 1 FrmeTyp 1 ReTx 1 Len 71：FC 8861 SN 197 PAN AE3 nAddr d80f

其中...
TS是从osal_GetSystemClock()获取的时间戳

CSMA是以下其中之一：
#define MAC_TX_TYPE_LEAD_CSMA 0x00
#define MAC_TX_TYPE_UNLETATE_CSMA 0x01
#define MAC_TX_TYPE_LEASEed 0x02
#define MAC_TX_TYPE_GREGE_POWER 0x03

FrmeTyp是"pMacDataTx->internal.frameType"

reTx是"txRetransmitFlag"的状态

len为"pMacDataTx->MSDU.len"

FC是数据包中的帧控制
sn是数据包中的序列号
PAN是数据包中的PAN ID
nAddr是数据包中的目的网络地址


因此，我们可以看到同一条消息发送了4次，快速连续重试了3次。

因此，有两个问题：
1)从osal_GetSystemClock()返回的代码的时间间隔是多少？
2)这些重试周期这么短是否正常/预期？

我在代码中注意到“macTxFrameRetransmit”是从库调用的，因此我看不到使用什么逻辑来确定何时执行重试。

启动应用程序时，您是否确认ZNP设备配置正确？

如果ZNP设备配置不正确，这将导致其他设备不加入网络(例如 NV写入错误，ZNP设备未立即启动OSAL，而是将保留"保持状态"以供等待高级网关应用程序配置NV项目并启动)

顺便说一下，您是否确认您的所有终端设备和协调员内置了相同的TCLK和网络密钥？如果没有，Join可能会死机。