This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您正在评估什么 SDK?您能否提供嗅探器日志并识别一些未加入的设备?您可以尝试增加 STACK_TASK_STACK_SIZE 和 APP_TASK_STACK_SIZE 来补偿此流量,或监视堆是否溢出,但最终 TI 不会针对此类使用情况测试 Z-Stack 解决方案,并建议您错开设备加入。如果您可以检测到问题已发生,您还可以从其应用程序代码触发协调器的重置。
(What SDK are you evaluating? Can you provide the sniffer log and identify some devices which do not join? You can try to increase the STACK_TASK_STACK_SIZE and APP_TASK_STACK_SIZE to compensate for this traffic, or monitor the heap for overflow, but ultimately TI does not test the Z-Stack solution against this type of usage and recommends that you stagger device joining. You can also trigger a reset of the coordinator from its application code if you can detect that the issue has occurred.)
hi, alex,经查是协议栈zd_app.c的函数有问题。
uint32_t ZDApp_ProcessSecEvent( uint8_t task_id, uint32_t events )
{
if ( events & ZDO_NEW_DEVICE )
{
.........................
while (pNewDevice )
{
pNewDevice->timeDelta -= timeDelta; //此处可能出现较小数减去较大数的情况!!!!!!!!!
pNewDevice = pNewDevice->next;
}
...........................................
}
函数ZDApp_ProcessSecEvent()里头while循环,相数相减可能出现异常(如短时间内大量设备加网的情况),导致pNewDevice->timeDelta等于接近于65535的值,单位为ms,约等于65秒的时间。
此数值又会影响函数ZDO_JoinIndicationCB() 的变量 timeToFire,导致65秒的时间内,向子设备发送association response后,一直不发送network key给子设备,一直得等65秒timeout后才恢复正常。
ZStatus_t ZDO_JoinIndicationCB(uint16_t ShortAddress, uint8_t *ExtendedAddress,
uint8_t CapabilityFlags, uint8_t type)
{
.................................
timeToFire = OsalPortTimers_getTimerTimeout( ZDAppTaskID, ZDO_NEW_DEVICE );
pNewDevice->timeDelta = ZDAPP_NEW_DEVICE_TIME - timeToFire;
// Start the timer only if there is no pending timer
if ( pNewDevice->timeDelta == ZDAPP_NEW_DEVICE_TIME )
{
OsalPortTimers_startTimer( ZDAppTaskID, ZDO_NEW_DEVICE, ZDAPP_NEW_DEVICE_TIME );
}
}
以上,请你们的工程师研究研究再修复。