主题中讨论的其他器件：CC2592、
您好！
我们使用 CC2652R 和 CC2592有一个非常简单的设计、并且我们使用 SimpleLink CC13x2 26x2 SDK 4.20.01.04堆栈。 我们在数十种产品上运行我们的路由器应用、该应用通常运行良好。
在测试过程中、我们看到其中一台路由器将通电并能够发送和接收 几秒钟、但之后、它不再发送或接收任何数据。 通过使用监听器捕获、我们可以看到它发送的数据包具有强大的 RSSI (即–40或-50dBm)。 但经过一段时间(2-15？)后、它不会路由、重复广播、甚至不会发送链路状态数据包。
我们在路由器上检测了用于看门狗的代码、如果它在35分钟内没有收到任何数据包、则会将其重置、而在重置后、它会正常运行。 路由器很少进入这种状态、也不是持久的。
当35分钟计时器到期而未收到任何数据包时、我编写了代码从堆栈 和应用程序中读取一组值、并将它们写入到非易失性 blob 中。 复位后、我会在一个特殊的数据包中发送这个 blob、以帮助我们了解堆栈在未发送或接收任何内容时所处的状态。 下面是一些我要保存的数据项、以及如何获得它们。
1.堆栈对 PAN ID 和通道的看法、以及 RX_ON_TIME_IDLE 标志以及它们是否属于网络的一部分：
- 我 每15秒调用 Zstackapi_sysConfigReadReq ()并读取 panID、chanList、macRxOnIdle 和 devPartOfNetwork 值。 当路由器进入这种坏状态且35分钟计时器超时时时时，我会在看门狗复位软件前将最近读取的值保存为 nonvol。
2.如果堆栈认为它已连接：
- 使用 Zstackapi_sysConfigReadReg ()命令读取 devPartOfNetwork 字段的方法可能是多余的。
- 如果 bdbCommissioningStatus 为 BDB_justing_Success，则在 App_Process 中的 zclGeneringstatus()函数中将布尔标志设置为 true。 或者、如果状态不是 BDB_TRUSION_SUCCESS、我将布尔标志设置为 FALSE。
3.监视 ZStackMessages 以查看是否收到任何"离开"或其它意外消息。
- 在 zclGenericApp_processZStackMsgs()中，如果最近的事件与最近收到的事件不匹配，我会将其移入 U32，并保留接收到的栈消息数的计数器。 这将跟踪4个最近的堆栈事件并提供接收到多少个堆栈事件的计数器。
4.发送数据包状态
- 我们的应用每15秒向协调器发送一个数据包。 我跟踪我们认为正在发送的数据包数量,以及来自 AF_DataRequest ()的返回状态值。
5.收到的数据包的数量
- 每次 调用 zclGenericApp_processAfIncomingMsgInd()时，我都会递增计数器。 协调器每隔几分钟发送一次应该收到的广播命令。
6.发送功率级别
- 我在 设置发射功率时在 ZMacSetTransmitPower()中设置一个值。
还有许多其他字段、但这些是大多数与堆栈相关的设置。 当路由器复位并发送调试信息时、我提取了以下信息：
#1 - 从 Zstackapi_sysConfigReadReq ()读取的值表示 panID 和通道是正确的。 RxOnWhenIdle 设置为 true，devPartOfNetwork 设置也为 true。 因此、堆栈似乎认为其已连接并在正确的通道和 PAN ID 上运行。
#2 -我的布尔值"加入"标志被设置为 true。
#3-最近的 ZStack 消息包括： BDB_Notification (0xc5)、 AF_DATA_CONFIRM_IND (0x91)和 INcoming_MSG_IND (0x92)。 (有两条0x91消息。) 接收到的堆栈消息的数量是4。
#4-计数器中的应用程序消息数为140，与预期的数字相匹配(4每分钟* 35分钟= 140)。 最近的 AF_DataRequest()返回状态为成功。 应用程序会在应该发送的时候发送消息、堆栈会以成功状态进行响应、即使从监听器捕获中看不到这些消息或协调器收到这些消息也是如此。
#5-接收的数据包数量只有1个。
#6 -发射功率等级被设定为我们所期望的值(0xF7)、或者-9dBm。 (请记住、这是馈送到 CC2592的功率级别。)
我还注意到、当路由器在35分钟超时后重置时、它会关联并加入新网络、并接收到新的短地址。 这似乎表明堆栈设置或其他设置有问题、使其加入而不是仅在其当前网络上恢复操作。
--
根据我的判断、当路由器停止发送或接收时、堆栈会认为它已连接到正确的网络、功率级别设置正确、堆栈会认为它应该能够传输数据包、因为它没有丢弃错误。 几个问题：
1.这些结论是否有效? 我是否要读取正确的 API、以了解堆栈是否认为它已加入、以及它认为它在哪个通道和 PAN ID 上运行？ 或者有没有更好的方法来获取这些信息？ 我出于某种原因想知道对讲机是否在其他信道上运行、但似乎没有。
2.是否有我们可以调用的任何其他 API 或可以检查的设置、以便尝试找出对讲机不传输或接收的原因、或确认对讲机或堆栈当前是否已启用？
3.我们是否有任何其他硬件引脚或固件设置用于解决此故障？
--
最后、我们刚刚注意到、此问题似乎与 此处报告的问题非常相似、尽管那是在多年前发布的、使用的是旧得多的堆栈。 但附近确实有 Wifi 路由器、因此信道干扰可能是罪魁祸首。 如果这与链路中的问题类似，我应该能够像文章中所建议的那样通过监视链路开销大于0的邻居的数量来检测问题，然后在路由器降为0时重置路由器。
