[参考译文] CC2530：每当 ZigBee 执行定向(加入网络)时、看门狗超时就会意外发生

您的意思是"看门狗超时意外"？

大家好、

您的器件 Zed/ZC/ZR 的角色是什么？  在 Zigbee 应用中、您在哪里踢看门狗？  我不建议依靠 osal_run_system 每秒循环一次、您至少应该初始化计时器以确保 安全装置被可靠地寻址。

此致、
Ryan

我同意 Ryan 的意见，即 在 ZC 和 ZR 中的 osal_run_system 之后启动看门狗是可以的，但对于休眠终端设备而言，这种设备可能不会在每秒唤醒一次。 对于休眠式终端设备、您应该启动一个小于1秒的周期性事件以启动看门狗。

我们的角色是 ZR，因此不要永远休眠，看门狗超时会在转向时导致错误的振荡重置，在设备转向时可能不会启用看门狗？

我不认为 bdb 调试会使 osal_sytemm_run 无法正常工作。 您能否使用原始的 Z-Stack 示例并仅添加看门狗来测试您是否遇到了相同的问题？

由于 ZR 器件无需初始化链路密钥表或执行其他 ZC 和 TC 网络形成任务、因此我也不希望有很长的转向时间。  您是否对默认堆栈设置进行了任何更改？

此致、
Ryan

您好、Ryan、

有时，由于环境原因，ZR 会很难加入网络，因此我们必须在 zclSampleLight_ProcessCommissioningStatus 回调中重试转向。

zclSampleLight_RetryTimes 变量的默认值为10、因此我们重试10次、如果找不到适合加入的网络、我们将放弃。但是、无论何时转向重试、看门狗超时都是意外的(似乎转向导致 osal 阻塞加班1秒)

我们在  zclSampleLight_Init 末尾调用 bdb_StartCommissing (BDB_commissioning_mode_NWK_Steering)来初始化转向加电。

代码段如下所示：

static void zclSampleLight_ProcessCommissioningStatus(bdbCommissioningModeMsg_t *bdbCommissioningModeMsg)
{
    switch(bdbCommissioningModeMsg->bdbCommissioningMode)
    {
        case BDB_COMMISSIONING_FORMATION:
            if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
            {
                //After formation, perform nwk steering again plus the remaining commissioning modes that has not been process yet
                bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | bdbCommissioningModeMsg->bdbRemainingCommissioningModes);
            }
            else
            {
                //Want to try other channels?
                //try with bdb_setChannelAttribute
            }
            break;
        case BDB_COMMISSIONING_NWK_STEERING:
            if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
            {
                // we are steering success,turn off indicate LED
                HalLedSet(HAL_LED_8, HAL_LED_MODE_OFF);
            }
            else if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_IN_PROGRESS)
            {
                // DO nothing at present
            }
            else
            {
                if(zclSampleLight_RetryTimes > 0)
                {
                	// we will retry steering again
                    zclSampleLight_RetryTimes--;
                    bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | bdbCommissioningModeMsg->bdbRemainingCommissioningModes);
                }
                else
                {
                	// we have to give up,turn off indicate LED
                    HalLedSet(HAL_LED_8, HAL_LED_MODE_OFF);
                }
            }
            break;
        case BDB_COMMISSIONING_FINDING_BINDING:
            if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
            {
                //YOUR JOB:
            }
            else
            {
                //YOUR JOB:
                //retry?, wait for user interaction?
            }
            break;
        case BDB_COMMISSIONING_INITIALIZATION:
            //Initialization notification can only be successful. Failure on initialization
            //only happens for ZED and is notified as BDB_COMMISSIONING_PARENT_LOST notification

            //YOUR JOB:
            //We are on a network, what now?

            break;
#if ZG_BUILD_ENDDEVICE_TYPE
        case BDB_COMMISSIONING_PARENT_LOST:
            if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_NETWORK_RESTORED)
            {
                //We did recover from losing parent
            }
            else
            {
                //Parent not found, attempt to rejoin again after a fixed delay
                osal_start_timerEx(zclSampleLight_TaskID, SAMPLEAPP_END_DEVICE_REJOIN_EVT, SAMPLEAPP_END_DEVICE_REJOIN_DELAY);
            }
            break;
#endif
    }


}

如果看门狗有助于解决超时问题、则在调试期间脚踢看门狗没有问题。

此致、
Ryan

 似乎在 f8wConfig.cfg 中设置-DDEFAULT_CHANLIST=0x07FFF800可能会导致每当转向时 WDT 超时。

听起来、当启用大量通道时、会导致测试中的 WDT 超时。 然而，我认为它没有理由这样做。 您是否尝试在调试期间添加踢看门狗？