[参考译文] CC2650EMK：停止发送数据包和停止信标请求

尊敬的 Yuya：

感谢您提供监听器日志。  您提到的行为会在0x7E85断开与协调器的连接后发生 、并且在孤立之后必须重新加入。  温度测量报告属性命令是基于 ZED 上的绑定自动发送、还是由应用程序手动触发？  如果是自动的、您是否能够通过重新加入流程来确认绑定是否得到维护？  无论在任何速率下、从数据包重试次数可以明显看出0x7E85和协调器的无线电连接不良。  这些器件应该移动得更近一些、消除物理屏障/通道干扰、并且/或者增加其传输功率。

请注意、不建议将 CC2650用于新的 Zigbee 项目、因为它无法支持1.2.2 HA 以上的 Z-Stack 版本(几年前已弃用)、并且没有足够的内存来支持强大/可靠的解决方案。  我建议  尽可能迁移到 CC2651R3。

此致、
瑞安

您好、Ryan、

感谢您的快速回复。

我的答复如下。

温度测量报告属性命令是基于 ZED 上的绑定自动发送、还是由应用程序手动触发？   

答案 我认为 温度测量报告属性命令会根据位于 ZED 上的绑定自动发送。 器件设置为在找不到其协调器时自动重新连接。(请查看大约4：50的数据包数据。)

如果是自动的、您是否能够通过重新加入流程来确认绑定是否得到维护？

答案 我无法确认绑定是否已维护。  是否有我可以检查以了解绑定是否得到维护的 API？  

这些器件应该移动得更近一些、消除物理屏障/通道干扰、并且/或者增加其传输功率。

答案  我将尝试更改器件的放置位置。

为什么此器件 未发送 Orphan 通知和信标请求？  

此致、

余亚市  

您可以参考 bindFindExisting (来自 ZStackCore 工程的 BindingTable.c/h)和/或 使用 osal_NV_READ 读取 ZCD_NV_Binding_table NV 项。 如果器件已进入退避模式(请参阅类似的 退避 并 重新加入 E2E 线程)、那么器件可能不会尝试重新加入、但另一个选项是由于存储器泄漏/损坏或某些其他硬件断言、应用程序已崩溃(需要进一步的器件调试才能确认)。

此致、
瑞安

我使用应用程序调试检查内存泄漏和其他问题。

论坛中是否有任何关于 Z-stack 内存泄露或 Z-stack 崩溃的报告？  应用是否有办法知道 Z-stack 已停止？

此致、

余亚市

您可以在 E2E 中搜索与 Z-Stack 内存泄漏和崩溃相关的线程。  如前所述、由于器件的限制、CC2650上的 Z-Stack HA 1.2.2a 更容易受到问题的影响。

https://e2e.ti.com/f/1/t/906365 
https://e2e.ti.com/f/1/t/902631 

halAssertHandler 将确定在代码生效时应执行的操作。

此致、
瑞安

如果器件已进入退避模式、则可能不会尝试重新加入(请参阅类似的 退避 并 重新加入  E2E 线程)

Z-stack 重复 DEV_Nwk_BACKOFF 和 DEV_Nwk_DESC 状态、但状态可能不会从 DEV_Nwk_BACKOFF 变为吗？

那是什么状态？

此致、

余亚市

除非退避计时器死后消失、否则器件绝不应从 DEV_Nwk_BACKOFF 状态变为

感谢您的快速回复。

也就是说、当回退计时器消失时、器件会从 DEV_Nwk_BACKOFF 变为吗？

在 Z-Stack Home 1.2.2a 实现中、ZDO_REJING_BACKOFF 计时器事件实际上会以不同的超时参数 zgDefaultRejoinScan 和 zgDefaultRejoinBackoff 开始、因此它不会消失。

Unknown 说：

如果设备已输入退避，则设备可能不会尝试重新加入[/报价]

以上摘自 Ryan 的答复。

我 想知道 上述状态是否发生？

但这是否意味着不会发生该状态？

在 Z-Stack Home 1.2.2a ZStackCore 实现中、当 startMode = MODE_RESUME 且 logicalType 是 ZDO_StartDevice 中的终端器件时、将调用 osal_start_timerEx (ZDAppTaskID、ZDO_REJING_BACKOFF、zgDefaultRejoinScan)

为避免进一步混淆、请参阅 ZStack_home_1_02_02a_44539\Documents\Z-Stack TI-RTOS Developer Guide.pdf 的第7章(便携式设备)：

如果终端设备在轮询期间丢失其父设备、它会扫描当前活动的信道并尝试安全重新加入、如果无法找到其网络、它将尝试扫描所有信道。 如果尝试安全重新加入(当前和所有信道)失败、网络密钥将被删除、设备将尝试重新加入信任中心(不安全)。 终端设备老化后、将尝试重新加入网络。 重新加入不取决于"关联许可"标志的状态。 当终端设备处于"重新加入"状态(扫描和重新加入尝试)时、它将在定义的时间段内(默认为15分钟)处于"重新加入"状态、然后进入"退出"周期(静默状态)(默认为15分钟)、然后循环回到"重新加入"状态。 可以通过应用程序映像使用以下代码配置这些持续时间：
ZStack_sysConfigWriteREQ_t writeREQ =｛0｝；
//设置重新加入状态持续时间–10分钟(600,000毫秒)
writeReq has_rejoinScanDuration = true；//激活参数
writeReq .rejoinScanDuration = 600000；
//设置退出重新加入状态持续时间–10分钟(600,000毫秒)
writeReq has_rejoinBackoffDuration = true；//激活参数
writeReq .rejoinBackoffDuration = 600000；
//发送系统配置写入请求
(void) Zstackapi_sysConfigWriteREQ (appEntity、&writeREQ)；

此致、
瑞安

我已经阅读了该文档。
我理解以下几点。

如果终端设备在轮询期间丢失其父设备、Z-stack 状态将从 DEV_END_DEVICE 更改为 DEV_Nwk_孤立 并发送孤立通知。
之后 、Z-stack 的状态从 DEV_Nwk_simplant 更改为 DEV_Nwk_DISC 并发送信标请求。
而 Z-stack 则重复 DEV_Nwk_DISC 和 DEV_Nwk_BACKOFF 状态。
当该状态为 DEV_Nwk_backoff 时、Z-stack 不发送 beacon_request。

我的器件配置如下。

f8wConfig.cfg
DDEFAULT_CHANLIST=0x00001000 (仅使用)
-DREJOIN_BACKOFF=60000
-DREJOIN_SCAN =120000

我认为问题在于、Z-stack 的状态并未从 DEV_END_DEVICE 变为 DEV_Nwk_orphan。
这些问题是否已在论坛中发布？

我有一个问题要问 HALassertHandler。
我的 应用基于 SampleTemperatureSensor 代码。
示例代码已实现 HALassertHandler。
该处理程序在没有额外配置的情况下检测并处理 z-stack 错误吗？

此致、
余亚市

您向 此论坛提供您的理论、但不提供基于您的发现的任何证据。  在此应用行为期间、您是否调试了器件状态？  您 能够在 E2E 论坛上搜索类似的实例/实例。

HAL 断言作用于硬件/堆栈故障、但不能依赖应用程序代码实现的错误行为。

此致、
瑞安

我很抱歉。
我已经使用串行输出调试了我的应用。
请参阅随附的文件。

我的应用程序每10秒向 ZC 发送一次数据(TEMPSENSOR_DATASEND_EVENT)。
应用程序通过 iCall_Wait 后、它查询 Z-stack 的状态、并 通过串行通信进行输出。

此致、
余亚市

e2e.ti.com/.../debug.zip

感谢您发送编修。  ZStack_DevState_Nwk_simplant 为10、因此 seriallog.txt 显示器件 状态从 DEV_END_DEVICE 变为 DEV_Nwk_simplant、然后显示 DevState_Nwk_doc/DevState_Nwk_backoff、 后者也反映了孤立状态。

此致、
瑞安

您好！

遗憾的是、我无法提供任何日志、因为此调试 ZE 不存在该问题。
我仍在调试、因此在获取日志时我会再次询问。

我在论坛上搜索了"Orphan Notification"字样、但没有发现任何类似问题。

我是否需要在 f8wconfig.cfg 中注释-DASSERT_RESET 才能使用 HAL 断言重置？

此致、
余亚市

如果您希望器件在发生 assert 时复位、则可以从"//-DASSERT_RESET"中删除"//"字符。

此致、
瑞安

您好！

感谢您的更多日志。  如果可以确认  正在执行 ZD8p_StartJoiningCycle -> ZD8p_NetworkInit、但未有效地将孤立器件重新加入网络、则 Z-Stack 无线电层可能会处于故障状态、这可能不会触发断言。  在这种情况下 、您应该监视应用程序行为并调用 SystemResetSoft 以重新启动固件。

此致、
瑞安

您好！  

我想检查一下 HALASSERTHandler 是否起作用。
因此、我想介绍如何轻松地激活 HALassertHandler。
你有什么想法吗？

我找到 SystemResetSoft()函数的文档。
我知道这是一个 TI-RTOS 函数、但有没有任何文档？

此致、
余亚市

您应该能够使用 HAL_assert 函数强制 HAL 断言。  SystemResetSoft -> SystemReset -> HAL_SYSTEM_RESET 没有文档、但是对复位寄存器的写入、即  HWREGBITW ( AON_SYSCTL_BASE + AON_SYSCTL_O_RESETCTL 、AON_SYSCTL_RESETTL_SYSRESETBITN )= 1；

此致、
瑞安

您好！

我现在正在尝试确保 HALAssertHandler 正常工作。
我有几个问题。
1. HAL_assert 函数是否是在 hal_assert.h 中定义的宏？
2.此宏是否调用了 HAL_ASSERT_Handler 以及 halassert.c 中定义的函数？
当 ZD 将状态从 DEV_Nwk_BACKOFF 更改为 DEV_Nwk_DISC 时、Z-stack 会调用 HAL_ASSERT_FORCED 函数(请参阅 ZDAP.c 第499行)。
我预期的行为是调用应用的 main.c (请参阅 main.c 第315行)中定义的函数并显示调试语句。 但是，它没有这样做。

e2e.ti.com/.../5141.ZDApp.ce2e.ti.com/.../8030.main.c

3.何时调用 main.c 中定义的 hal_assert_handler？ 我如何才能确认它是否有效？
此致、
余亚市

对于任何混淆、我深表歉意、但您似乎忽略了 HAL 断言的目标。  它们是独立的操作、当出现可能由应用程序执行引起的硬件问题时会发生。  用户可以确定 HAL 生效后采取的操作(复位、闪烁指示灯、旋转等)、但不应直接调用/强制 HAL 生效。   在到达相关代码后、只需执行您希望完成的操作。

此致、
瑞安