主题中讨论的其他部件：CC2531、 CC2530、 Z-stack、 CC2592
本页面包含 TI 发布的 Zigbee 软件版本的已知问题。 TI 有一个软件版本候选项、所有修复程序在实施后可能不会立即对开发人员可用。 此页面的目的是为开发人员提供问题和修复的信息、以防在发布新版本之前在已发布的软件上发现问题。 这将帮助开发人员在 TI 发布的 Zigbee 版本中修复问题之前修复问题。
zcl.c 中的内存泄漏
问题描述：
zcl_HandleExternal()中的内存泄漏
建议的修复：
zcl_HandleExternal()
{...
#ifdef BDB_报告
if (pcmd->zclHdr.commandID =ZCL_CMD_CONFIG_REPORT)
｛
BDB_ProcessInConfigReportCmd (pCmd)；
OSAL_msg_deallocate (((uint8 *) pCmd)；//++++++++++++++++++ 添加此代码
返回 true；
｝
if (pcmd->zclHdr.commandID =ZCL_CMD_READ_REPORT_CFG)
｛
BDB_ProcessInReadReportCfgCmd (pCmd)；
OSAL_msg_deallocate (((uint8 *) pCmd)；//++++++++++++++++++ 添加此代码
返回 true；
｝
#endif...
｝
2.在以前的 APS 删除或离开请求后出现网络关联问题
问题描述：
在某些情况下、当向设备发送 APS 取药/离开请求以取出自己或另一个设备时、NV 将无法正确清除、新的网络关联将无法工作、因为来自 TC Link 密钥交换的旧 APS 密钥在 NV 中持续存在。
建议的修复：
//在 ZDrapp.c
UINT16 ZDUApp_EVENT_LOOP (uint8 task_id、UINT16事件)
{...
if (events & ZDO_DEVICE_RESET)
｛
#ifdef ZBA_FRESETY_NWKKEY
if (devState == dev_end_device_unauth)
｛
ZDSecMgrFallbackNWKKey()；
}
否则
#endif
｛
//设置 NV 启动选项以强制"新建"加入。
zgWriteStartupOptions (ZG_STARTUP_SET、ZCD_STARTOPT_DEFAULT_NETWORK_STATE | ZCD_STARTOPT_DEFAULT_CONFIG_STATE)；//++修改此行+++
//设备已处于取消验证状态，因此请重置
//注意：此呼叫不会返回
SystemResetSoft()；
}
}...}
3.由于 CC2530/CC2531上的 BDB_REPORTING 而导致的软复位/冻结/堆栈溢出
问题描述：
XDATA 堆栈的默认大小为0x300 (768字节)、并且随着应用程序中添加 BDB_REPORTING、调用堆栈有时会变得太大并溢出 XDATA 堆栈。
建议的修复：
将项目选项中 XDATA 堆栈的大小至少增加到 0x400：
4.从 ZHA 1.2到 Z3.0的 OTA 升级会导致器件损坏
问题描述：
在从 ZHA 1.2进行 OTA 升级到 Z3.0时、某些 NV 项目在不同版本之间的使用发生了变化、网络安全信息的格式设置也不同。 因此、我们在进行此升级时必须"升级"一些 NV 安全项目。
建议的修复：
下面的一些代码已存在于 Z-Stack 中并作为上下文提供。 添加此修复程序的所有代码更改均位于编译标志 upgrade_security_nv_items 下
//在 ZGlobals.c
中/
*本地函数
*/...
#ifdef upgrade_security_nv_items
static void zgUpgradeSecurityNVItems( void )；
#endif // upgrade_security_nv_items...
uint8 zgInit( void ){...
#ifndef NONWK
if (ZG_SECURE_ENABLED)
｛
//将预配置密钥初始化为默认密钥
zgPreconfigKeyInit( setDefault );
//初始化所有键的 NV 项目：NWK、APS、TCLK 和 Master
ZDSecMgrInitNVKeyTables (setDefault)；
｝
#endif // NONWK
#ifdef upgrade_security_nv_items
zgUpgradeSecurityNVItems()；
#endif // upgrade_security_nv_items
//清除 Config State default
if (setDefault)
{
zgWriteStartupOptions (ZG_STARTUP_CLEAR、ZCD_STARTOPT_DEFAULT_CONFIG_STATE)；
}
#ifdef upgrade_security_nv_items
static void zgUpgradeSecurityNVItems( void )
{//nV
配置，允许从 HA1.2升级到 Z3.0
uint8 isOnANetwork=1；
//read bdb 属性
if (osal_nv_read(ZCD_nv_BDBNODEISONAsizWORK，0, eof)=uint8 (uNetwork)
//升级后，此参数将为0，然后正确更新，就像在网络中一样。
//如果设备不在网络中并且已升级，BDB 将处理该网络
//配置状态、并将执行 FN 复位。
nwkSecMaterialDesc_t nwkSecMaterialDesc；
nwkActiveKeyItems 键项;
uint8 KeyAttributes；
uint8 tempKey[SEC_KEY_LEN]；
OSAL_memset (tempKey、0x00、SEC_KEY_LEN)；
//从旧 NV 项目获取网络帧计数器，同时检查是否存在旧密钥。
//如果没有，我们可以假设这是出厂时新的 Z3.0设备，而不是
//升级了 ZHA 1.2设备
OSAL_NV_READ( ZCD_NV_NWKKEY、0、sizeof ( nwkActiveKeyItems )、(void *)&keyItems )；
if (osal_memcmp (tempKey、keyItems.active.key、SEC_KEY_LEN))
｛
//设备是新出厂的，不执行任何操作
}
//否则，如果节点当前不在网络上并且不是工厂新的 Z3.0设备，
//它必须是升级的 ZHA 1.2 -> Z3.0.1设备
否则 if (！isOnANetwork)
｛
//如果 nV 操作无法配置这些参数，则 BDB 将能够初始化或处理。
//将 bdbNodeIsOnANetwork 属性设置为1，指示我们需要恢复网络状态
isOnANetwork = 0x01；
OSAL_NV_WRITE( ZCD_NV_BDBNODEISONANETWORK，0，sizeof (uint8)，&isOnANetwork )；
//在新的 NV 项目中设置网络帧计数器，在 ZDRApp_RestoreNWkSecMaterial()中，帧计数器将递增1000+250
//确保其出站数据包可供其上一个网络中的设备使用
nwkSecMaterialDesc.FrameCounter = keyItems.frameCounter;
//从 NV 中的 NIB 检索扩展 PANID
OSAL_NV_READ (ZCD_NV_NIB、osal_offsetof (nwkIB_t、extendedPANID)、Z_EXTADDR_LEN、&nwkMaterialDesc.extendedPanID)；
//设置 BDB 网络安全材料，如果这是有效的条目，BDB 状态机将恢复网络状态
OSAL_NV_WRITE (ZCD_NV_NWK_SEC_material_table_start、0、sizeof (nwkSecMaterialDesc_t)、&nwkSecMaterialDesc)；
//向 BDB 表明我们之前的 NWK 不是 R21，因此不要期望 TC Link 密钥交换
KeyAttributes = ZG_NON_R21_NWK_Joined；
OSAL_NV_WRITE (ZCD_NV_TCLK_Table_start、osal_offsetof (APSME_TCLKDevEntry_t、keyAttributes)、sizeof (uint8)、&keyAttributes)；
｝
}
#endif // upgrade_security_nv_items
5.错误报告 CC2538ZNP 的 IEEE 地址
问题描述：
使用 CC2538ZNP 项目时、IEEE 地址的 MSB 和 LSB 翻转。 这是因为在 CC2538 SoC 器件的测试和生产版本之间、IEEE 地址在闪存中的位置发生了变化。 非 ZNP CC2538ZNP 项目不受影响、因为它们使用不同的 ZMain.c 文件、该文件已经对此应用了修复程序。
建议的修复：
//在 ZMain.c 中针对 CC2538ZNP /********* *本地定义 *// TI IEEE 组织唯一标识 符#define IEEE_OUI 0x00124B... //将 zmain_ext_addr()替换为 静态 void zmain_ext_addr (void) ｛ uint8 nullAddr[Z_EXTADDR_LEN]=｛0xFF、0xFF、0xFF、0xFF、0xFF、0xFF、0xFF、0xFF、 0xFF、0xFF、0xFF｝； uint8 writeNV = true； //首先检查 OSAL NV 中是否存在未擦除的扩展地址。 if ((Success！= osal_nv_item_init (ZCD_nv_EXTADDR、Z_EXTADDR_LEN、NULL)))|| (成功！= osal_nv_read (ZCD_nv_EXTADDR、0、Z_EXTADDR_LEN、扩展地址))|| (OSAL_memcmp (aExtendedAddress、nullAddr、Z_EXTADDR_LEN) )｛ //尝试从最后一个闪存中的位置读取扩展地址 //调试工具知道要保留的页面。 if (！osal_memcmp (((uint8 *) HAL_flash_IEEE_ADDR、nullAddr、Z_EXTADDR_LEN))) ｛ (空) osal_memcpy (aExtendedAddress、(uint8 *) HAL_flash_IEEE_ADDR、Z_EXTADDR_LEN)； ｝ 其他 ｛ //从信息页读取时禁用预取。 uint32 fctl = HWREG (FLASH_CTRL_FCTL)； HWREG (FLASH_CTRL_FCTL)= fctl &~(FLASH_CTRL_FCTL_Prefetch_enable)； //从信息页复制64位扩展地址 (void) osal_memcpy (aExtendedAddress、(uint8*) HAL_INFO_IEEE_ADDR、Z_EXTADDR_LEN)； if (！osal_memcmp (扩展地址、nullAddr、Z_EXTADDR_LEN)) ｛ uint32 oui = IEEE_OUI； // IEEE OUI 位于8字节扩展地址的高3个字节中 //早期测试 CC2538EM 的第2个字中包含 TI OUI、 //生产 CC2538器件的 TI OUI 位于第一个字中 if (osal_memcmp (&aExtendedAddress[1]、&oui、3)) ｛ //在第一个字中找到 OUI，交换字以将 OUI 放在高字节中 (空) osal_memcpy (aExtendedAddress、&aExtendedAddress[4]、Z_EXTADDR_LEN/2)； (空) osal_memcpy (&aExtendedAddress[4]、(uint8*) HAL_INFO_IEEE_ADDR、Z_EXTADDR_LEN/2)； ｝ ｝ else //未找到有效的扩展地址。 ｛ uint8 idx； #if！defined (nv_restore) writeNV = false；//创建临时 IEEE 地址，不保存在 NV #endif 中 /*创建一个足够随机的扩展地址以方便地进行访问。 *注意：这仅在测试环境和中有效/合法 * 不得用于商业产品。 * 对于(idx = 0；idx <(Z_EXTADDR_LEN - 2)；) ｛ uint16 Randy = osal_rand()； aExtendedAddress[idx++]= LO_UINT16 (Randy)； aExtendedAddress[idx++]= HI_UINT16 (Randy)； ｝ // MSB 下一个标识 ZigBee 器件类型。 #if ZG_build_Coordinator_type &&！ZG_build_Join_type aExtendedAddress[idx++]= 0x10； #Elif ZG_build_RTRONLY_TYPE aExtendedAddress[idx++]= 0x20； #else aExtendedAddress[idx++]= 0x30； #endif // MSB 具有历史标志。 aExtendedAddress[idx]= 0xf8； ｝ //将闪存控制恢复到以前的状态 HWREG (FLASH_CTRL_FCTL)= fctl； ｝ if (writeNV) ｛ (空) osal_nv_write (ZCD_NV_EXTADDR、0、Z_EXTADDR_LEN、aExtendedAddress)； ｝ } //根据上述结果设置 MAC PIB 扩展地址。 (空) ZMacSetReq (MAC_extended_address、aExtendedAddress)； ｝ ...
6.修改 CC2538链接器以利用所有32k RAM 会导致锁定
问题描述：
某些 CC2538器件具有32k 的 RAM、但默认情况下、我们的链接器文件中会禁用第一个16k、因为在所有功耗模式下仅保留第二个16k。 当器件进入 PM2时、第一个16k RAM 丢失其内容。 如果您正在设计从不进入低功耗模式的器件、则可以回收此 RAM 以供应用使用。 您可以通过更改链接器文件中的以下内容来实现此目的：
// //为片上 SRAM 定义一个区域。 // 定义区域 SRAM =内存：[从0x20000000到0x20007FFF]；// 0x20004000 -> 0x20000000
但是、在某些应用中、将 RAM 增大到该值将导致 Z-Stack 锁定。
建议的修复：
将运行时堆栈移动到 RAM 的末尾。 在链接器文件中找到以下代码并进行以下更改：
//
////指示 noinit 值应保留。 这包括
//堆栈、如果被初始化、将破坏
//初始化代码的返回地址、导致处理器分支为零并产生故障。
//
不要初始化{ SECTION .noinit }；
将其放置在 SRAM 的末尾{ SECTION .noinit }；//++++++++++++ 添加此行++++++++
7. ZED 不接收从父级发送到 MAC DST 0xFFFF 的广播
问题描述：
在 Zigbee 中、如果广播消息发送到目标地址0xFFFF、则所有器件(Rx-Always On 和 Sleepy)都将接收此消息。 这意味着父路由设备必须缓冲发送到0xFFFF 的任何休眠 ZED 子级的广播。 在 Z-Stack 中、如果单个 ZR/ZT 节点具有超过(32 - MAX_neighbor entries)的直接休眠式 ZED 子节点、超过此数字的每个 ZED 都将无法接收广播消息。 对于 Z-Stack 中的路由器件、默认情况下 Max_neighber_entries 为16。
建议的修复：
由于此实现位于预编译的 Z-Stack 库中、因此目前还没有针对此提供完美的修复、但我们建议使用一些权变措施：
- 不要将广播消息发送到目的0xFFFF、只能使用0xFFFC/0xFFFD (MAC DST addr 仅适用于 Rx-Always On 设备)、并将单播消息发送到休眠 Zed 节点。
- 这是首选方法、因为这样您就不必限制器件表大小。
- 将每个 ZC/ZR 的休眠 ZED 节点数限制为最多16个
- 不管怎样、这对于大型网络来说都是一个很好的做法、对于稳健的网状网络拓扑、您应该始终针对每个10-15个 ZED 使用一个 ZR
- 将 MAX_neighbor entries 从16减小为较小的值
- 不建议使用 MAX_neighber_entries 来确定邻居表的大小，邻居表是 RF 范围内的 ZR 设备的列表。 邻居表越大= Zigbee 路由发现越简单=网状网络越强大。 TI Z-Stack 在 MAX_neighbor entries = 16条件下经过测试、对于大多数 Zigbee 网络情况而言都是一个很好的值。
8.调试期间，ZED 轮询(传输密钥、简单描述符请求等)时，NWK/APS 数据包重试/失败
问题描述：
有时、ZC 在网络调试期间无法将 NWK/APS 层数据包(例如传输密钥)发送到加入 ZED 的 ZED、这需要 ZED 再次轮询以获取数据包。 这不会导致加入器件出现功能问题、因为它将重试并最终获取数据包、但需要重试多次接收同一数据包并不理想。 此问题是由新器件加入网络后在 ZC 上发生的涉及阻塞 NV 写入操作的竞态条件引起的。
建议的修复：
将 ZDAPP_UPDATE_NWK_NV_TIME 的值从默认值700 (ms)更改为更大的值、如3500。 这将导致 NV 写入操作在稍后启动、从而不会干扰网络调试。
9. ZED 在失去父级并尝试恢复后不会返回低功耗状态
问题描述：
从 应用程序调用 API bdb_ZedAttempRectOverNWK()以尝试让 ZED 重新加入网络后，接收器不会重新关闭，这会导致 ZED 在空闲期间使 RX 保持开启状态，而不会进入低功耗状态。
建议的修复：
修改 bdb.c 中的函数 bdb_parentLost()：
void bdb_parentLost (void) ｛ #if ZG_build_ENDDEVICE_TYPE IF (ZG_DEVICE_ENDDEVICE_TYPE) ｛ while (pBDBListNWK) ｛ BDB_nwkDescFree (pBDBListNwk)； ｝ nwk_desc_list_free ()； if (bdbCommissioningProcedureState.bdbCommissioningState！= BDB_parent_lost) ｛ //如果父级在 TCLK 交换期间丢失，则报告 TCLK 交换失败 if (bdbCommissioningProcedureState.bdbCommissioningState = BDB_T调试 状态_TC_LINK_KEY_EXCHANGE) ｛ BDB_reportingState,(BDB_commissioning_State_TC_LINK_KEY_exchange，false)； 返回； ｝ bdbCommissioningProcedureState.bdb_ParentLostSavedState = bdbCommissioningProcedureState.bdbCommissioningState； ｝ bdbCommissioningProcedureState.bdbCommissioningState = BDB_parent_lost； NLME_OrphanStateSet()； ZDUApp_ChangeState ( DEV_NWK_孤立)； //在孤立状态下关闭接收器 字节 temp = false； //++++++++++++++ 添加此代码 ZMacSetReq (ZMacRxOnIdle、&temp)； //++++++++++++++ 添加此代码 BDB_reportmentioningState (BDB_parent_lost、false)； ｝ #endif ｝
10.通过 Zigbee 进行聊天+语音的 ZCL ID 混频
问题描述：
交换 ZCL ID
建议的修复：
//这就是它现在 的#define ZCL_CLUSTER_ID_telec通信_聊天的方式 0x0904 #define ZCL_CLUSTER_ID_telec通信_voice_over_ZigBee 0x0905 // ID 应交换如下： #define ZCL_CLUSTER_ID_telec通信_聊天 0x0905 #define ZCL_CLUSTER_ID_telec通信_VOICE_OVER ZigBee 0x0904
11. CC2530/1 ZNP 器件偶尔返回 ZMemError
问题描述：
有时、在我们的 Zigbee Linux 网关解决方案中、CC2530/1 ZNP 器件会返回状态为 ZMemError 的故障消息、如下所示。
[14：52：12.119、309][gateway/LSTN] PKTTYPE：[ z_stack<<<<<<<<< <<>NPIRVR ] [SRSP] 01：64：02：10 [14：52：12.145、559][NPIRVR/Main] PKT_hex：[ NPISRVR>>Z_STACK ] [ucst] 01：64：02：10 [14：52：12.146、349][Z_STACK/LSTN] PKTTYPE：[ Z_STACK_>>>>> 网关] zstackDefaultRsp [14：52：12.146、499][Z_STACK/LSTN] PKTBODY： cmdID = AF_DATA_REQ [14：52：12.146、567][Z_STACK/LSTN] PKTBODY： 状态= ZMemError [14：52：12.148、151][gateway/LSTN] PKTTYPE：[ 网关>>>>> CON007] GwZigbeeGenericCnf [14：52：12.148、413][gateway/LSTN] PKTBODY： cmdId = ZigBee_general_CNF [14：52：12.148、556][gateway/LSTN] PKTBODY： 状态= STATUS_FAILURE [14：52：12.148、679][GATEWAY/LSTN] PKTBODY： 序号= 0x000001A1 (417)
建议的修复：
增加 CC2530/1 ZNP 项目中堆的大小。 默认情况 下、ZNP 项目为2170个字节、对于某些应用程序来说太小。
您可以通过将此编译标志添加到项目的预处理器定义的符号来增大堆的大小：
MAXMEMHEAP=2800
要进一步增加堆(或者对于常规 RAM/闪存优化) 、请检查 SWRA635
12. ZC 在 MAC 关联后发送 ZED Leave Reqs
问题描述：
当尝试一次加入大量 ZED 时、ZC 有时会发送 ZED 离开(不重新加入)请求。 这是由于网络层数据缓冲区溢出造成的。 如果 ZC 由于网络层数据缓冲区中缺少空间而无法将传输密钥包缓冲到 ZED (用于缓冲休眠子级的间接消息)、ZC 将丢弃传输密钥、然后从其关联表中删除设备。 然后、在下次 ZED 轮询 ZC 数据时、ZC 将向其发送一个休假请求、因为 ZC 认为它是"流氓"、因为 ZED 不在其关联表中。
建议的修复：
1.错接 ZED 设备的连接，即使您的加入事件变得偶发(osal_rand() % 30000)<--介于0和30秒之间的随机时间量
2.立即加入更少的 ZED
3.如果 RAM 允许，增加网络层数据缓冲区的数量：
//在 NWK_globals.c 中 //将所有缓冲区的大小加倍： //数据缓冲区队列的最大值 #define NWK_MAX_DATABIFS_WAITING_16/8 //等待发送到 MAC #define NWK_MAX_DATABIFS_Scheduled 10//5 //要发送 的定时消息#define NWK_MAX_DATABIFS_Confirmed 10//5 //在 MAC 确认 #define NWK_MAX_DATABIFS_TOTAL 后保持 24 //12 //缓冲器总数
13.如果使用 zcl_TransID、APS 会确认 transID 参数错误
问题描述：
zcl_TransID 在 zcl_SendCommand()中用作 AF_DataRequest()的参数，但始终为零。 它只能使用、因为它不影响 APS 帧、并且 APS 标头具有正确的序列号、因此仅影响 APS ACK 验证。 因此、从该函数中删除 zcl_TransID 后、它将变为过时。
建议的修复：
请改用 APS_Counter，因为每次在 APSDE_FrameHdrSet()中生成 APS 帧时，此变量都会递增，并且具有 APS 帧的计数
//在 zcl.c extern uint8 DESC_Counter 的“外部变量”部分中； //在 zcl.c 的 zcl_SendCommand()中 填入命令帧 zcl_memcpy (pBuf、cmdFormat、cmdlen)； status = AF_DataRequest (destAdAPS、epdr、clusterID、cmsBuf、cmdlen)；status = AF_DataRef_DataRequest (destAdr、cmsgMtf、cmsf、cmsf、cmsf &APS_Counter，options，AF_DEFAULT_RADIUS)； zcl_mem_free (msgBuf)；
14. BDB 报告不支持读/写属性数据回调函数
问题描述：
当前的 BDB 报告实现不支持使用回调函数读取/写入属性数据的属性。
建议的修复：
替换 bdb_reporting.c 中的 bdb_RepFindAttrEntry()
uint8 gAttrDataValue[BDBREPORTING_MAX_ANALOG_ATTR_SIZE]； 静态 uint8 bdb_RepFindAttrEntry (uint8端点、uint16群集、uint16 attraID、zclAttribute_t* attraRes) ｛ epList_t * memDataCur = epList； uint8 _attra_attr 、zat_attr、z_attle_attle_attle_attle_attr； for (epCur = epList；epCur！= NULL；epCur = epCur->nextDesc) ｛ if (epCur->epDesc->endpoint =>端点==端点) ｛ zclAttrRecsList* attitItem = zclFindAttrRecsList( epCur->epDesc->EndPoint )； if ((attitItem！= NULL)&&(attitItem->numAttributes > 0)&&(attitItem->atttrs！= NULL)) ｛ 对于( i=0；i < attitItem->numAttributes；i++) ｛ if ((attrItem->attrs[i].clusterID == cluster)&&(attrItem->attrs[i].attr.atId == atterID)) ｛ uint16 dataLen； attrres->atrId = atitItem->attrs[i].attr.atrId; attrRes->datatype = atItem->attrs[i].attr.datatype； attrres->accessControl = attiterItem->attats[i].attr.accessControl； dataLen = zclGetDataTypeLength (atttrRes->datatype)； zcl_ReadAttrData( endpoint, cluster, attraes->attraId, gAttrDataValue,&dataLen )； attrRes->dataPtr = gAttrDataValue； 返回 BDBREPORTING_TRUE； ｝ } } 返回 BDBREPORTING_FALSE； }
15.由于 BDB 标头构建类型而产生的错误
问题描述：
如果-DZSTACK_DEVICE_BUIGE="（DEVICE_BUIGE_router | DEVICE_BUIGE_ENDDEVICE)"(来自 ZNP.cfg)、则某些标识符会保留为未定义。
建议的修复：
替换 bdb.h 的 include 和宏部分：
#if (ZG_build_Join_type ||(Zstack_device_build = device_build_router)||(Zstack_device_build = device_build_ENDDEVICE)//++更改此行 //可选 #if defined (inter_PAN)&&(defined (BDB_TL_initiator)|| define (BDB_TL_target)) #define BDB_TOUCHLINK_Capability 1 #else #define BDB_TOUCHLINK_FACTUATOR_ENABLED 0 #endif defined (inter_PAN)&&(defined (BDB_TL_INITIATOR)|| defined (BDB_TL_TARGET) #ERROR 无法为协调器启用 TouchLink。 请确保不要定义 BDB_TL_INITIATOR BDB_TL_TARGET #endif #endif /********* *宏 *// bdbNoteCommissioningCapability 宏 #if (ZG_build_Coordinator_type)#define BDB_network_steining_capability (BDB_network_steining_capability <0)#define BDB_network_formation_capability (BDB_formation_enabled<1) #define BDB_binding_capability (zDB_build_binding_capability (zbding_bding_enabled)<1<1)#define BDB_bding_enabled<1|#define BDB_bding_enabled<1_enabled<1|ENABLE_ENABLE_ENABLE_ENABLE_ENABLE_ENABLE_ENABLE_ENABLE_ENABLE_ENABLE_ENABLE //++更改此行 #define BDB_network_steering _capability (BDB_network_steering _capity_enabled<0) #define BDB_network_formation_capability (BDB_router_form_distributed_NWK_enabled<1) #define BDB_Finding_Binding_capability (BDB_Binding_capability (BDB_Binding_capability)#define BDB_ENABLE_TODB_END_ENABLECINDICING_ENABLE<3)#define BDB_CLUSDINDICINDICINDICINDICK_ENABLED (#define BDB_INDICING_ENCOUTTODB_ENCOUTTODB_IN (BDB_network_steering 功能启用<<0) #define BDB_network_forming_capability (0<1) //ZED 无法形成 NWK #define BDB_Finding_Binding_capability (BDB_Finding_Binding_Capability 启用<<2) #define BDB_TOUCHLINK_Capability (BDB_TOUCHLINK_TICENABLE_<3) #endif
通过注释协调器设置并添加路由器和设备构建来修改 f8wCoord.cfg：
/*协调器设置*///-DZDO_Coordinator //协调器功能 //-DRTR_NWK /*通用一体机设置*/ -DZSTACK_DEVICE_BUILD ="(DEVICE_BUILD | DEVICE_BUIGE_ENDDEVICE)"/* 其他设置*/ -DNWK_AUTO_POLL
使用-C $PROJ_DIR$\..\..\Librarys\TI2530DB\bin\AllDevice-Pro.lib 更改器件库，并将 #if (ZStack_router_build)|| Defined (ZBIT) (ZBIT)的所有实例替换为 #if (ZStack_router_build)||(ZG_BUIL_ENDIC_已定义)(ZBIT)类型|
16. ZED 重新加入时未进入低功耗模式
问题描述：
ZED 设备状态在重新加入时设置不正确、因此绕过进入待机状态和保持活动状态。 这会导致比预期的电流消耗更高。
建议的修复：
将 bdb_reportCommissioningState 的 bdb_parent_lost 和 bdb_initialization case 中的 dev_end_device 更改为 dev_NWK_SEC_REALIT_CURR_channel
17.在试运行前，ZED Factory New 不会进入低功耗模式
问题描述：
ZED 启动时的高电流消耗来自新工厂、然后再被调试到网络中。
建议的修复：
在 osal_pwrmgr.c 中更改以下内容：
#include "ZGlobals.h"
void osal_pwrmgr_init (void)
{
#if !defined use_ICALL &&!defined OSAL_PORT2TIRTOS
#if defined power_saving && Zstack_end_device_BUILD
pwrmgr_attribute.pwrmgr_device = PWRMGR_battery；//如果启用节能、则默认为 ZED 节能。
#else
pwrmgr_attribute.pwrmgr_device = PWRMGR_always_on；//路由设备不节能。
#endif
#endif /* use_ICALL */
pwrmgr_attribute.pwrmgr_task_state = 0； //清除。 全部设置为保留
#if defined use_ICALL || Defined OSAL_PORT2TIRTOS
pwrmgr_initialized = true；
#endif //* Defined use_ICALL || Defined OSAL_PORT2TIRTOS */
｝
18.如果从启用重新加入的休假请求重置，则 ZED 轮询率设置不正确
问题描述：
由于设置了重新加入选项的父休假请求而复位后、ZED 将使用重入_poll_rate 而不是 POLL_rate 进行轮询。
建议的修复：
在 ZDApp.c 的 ZDRAP_ProcessNetworkJoin 中，从 if (nwkStatus=ZSuccessess)中删除 NLME_SetPollRate( zgRefjoPollRate ) ， 然后将其放在 else 语句中。 当器件状态为 DEV_END_DEVICE_UNauth 时、还必须设置 zgRejoinPollRate
if (ZG_SECURE_ENABLED &&(ZDUP_RestoreNWKKey (TRUE)== false)
){
if (ZStack_END_DEVICE_Build)
{
NLME_SetPollRate (zgRefjoinPollRate)；
｝
//等待来自信任中心的授权
ZDUApp_ChangeState (DEV_END_DEVICE_UNauth)；
最好也将 NLME_SetPollRate( ZDUP_SavedPollRate )置于 ZDO_JoinConfirmCB 内部。
19. BDB 的 F&B 功能中的内存泄漏
问题描述：
bdb_ProcessSimpleDesc()中的内存泄漏
建议的修复：
添加 bdb_zclSimpleDescClusterListClean (&bdb_FindingBindingTargetSimpleDesc)； 如果 BDB F&B 未请求简单描述符响应，则在返回之前添加
//为了安全检查，这是一个有效的条目
if (pCurr != NULL ){
uint8 extAddr[Z_EXTADDR_LEN]；
if (AddrMgrExtAddrLookup (pCURr->data.addr.shortAddr、extAddr))
｛
isRespondReadyToBeAdded = true；
｝
其他
｛
//保存简单的描述，不要再要求它
pCURR_>SimpleDescriptor =&bdb_FindingBindingTargetSimpleDesc；
｝
(void) extAddr；//dummy
｝
else
｛
// BDB F&B 未请求此简单描述
BDB_zclSimpleDescClusterListClean (&bdb_FindingBindingTargetSimpleDesc)；//++添加此代码
返回；
｝
20.大量的地址管理器条目会导致较长的 ZC 启动时间
问题描述：
当增加 存储在 ZCD_NV_ADDRMGR 项目中的 NWK_MAX_ADDRESSES 值的数量(通过增加 ZDSECMGR_TC_DEVICE_MAX 和 NWK_MAX_DEVICE_LIST)时， 在 NLME_InitNV ()期间初始化 NV 项目所需的大量 OSAL_NV_WRITE 调用 将导致启动时间长时间延迟。
建议的修复：
初始化 Address Manager NV 项目的大部分而不是一次初始化一个字节、可通过如下修改 ZDUP.c 来实现此示例：
#define ADDR_Mgr_entry_size 12
uint8 Custom_AddrMgr_InitNV (void)；
//...
UINT8 ZDOInitDeviceEx (uint16 startDelay、uint8模式)
｛
//……
否则
｛
//清除 NV 中的网络状态
custom_AddrMgr_Initnv()；//添加此行
NLME_InitNV()；
NLME_SetDefaultNV()；
//清除 NWK 键值
ZDSecMgrClearNVKeyValues ()；
}//...
uint8 ZDApp_RestoreNetworkState( void )
{
uint8 nvStat；
nvStat = Custom_AddrMgr_InitNV()；
nvStat |= NLME_InitNV()；
//……
uint8 Custom_AddrMgr_Initnv( void )
{
uint8 ret =成功；
uint8状态，Ctrl[NWK_MAX_ADDR_Mgr_entry_size]；
uint16大小，索引， offset；
//初始化 NIB NV 项目
if (osal_nv_item_init (ZCD_nv_nb、sizeof (nwkIB_t)、&_NIB)=nv_Opper_failed)
RET |= NV_NIB_INIT_FAILURE；
SIZE =(uint16)(ADDR_Mgr_entry_size * NWK_MAX_ADDRESSES)；
status = osal_NV_IT_INIT (ZCD_NV_ADDRMGR、SIZE、NULL)；
if (status = NV_IT_UNINIT)
｛
对于(索引= 0；索引< NWK_MAX_ADDRESSES；index++)
｛
Ctrl[索引]= 0x00；
｝
对于(index = 0；index < ADDR_Mgr_entry_size；index++)
｛
偏移= NWK_MAX_ADDRESSES *索引；
OSAL_NV_WRITE( ZCD_NV_ADDRMGR，偏移量，NWK_MAX_ADDRESSES，&ctrl )；
}
}；
if (status =nv_Oper_failed) ret |= nv_ADDR_Mgr_init_failure；
返回( ret );
}
HAL_NV_PAGE_CNT 和 OSAL_NV_PHY_PER_PG 也需要相应增大。 OSAL_NV_PHY_PER_PG*2048必须大于 NWK_MAX_ADDRESS*12 ( AddrMgrEntryData_t 的大小)、CC2538.ICF 闪存 和 NV_MEM 区域应补偿对 HAL_NV_PAGE_CNT 的更改
包括 HAL_PA_LNA_CC2592不会传播到 ZNP 项目
问题描述：
与所有家庭自动化示例相比、hal_board_cfg.h 中涉及 HAL_PA_LNA_CC2592的案例并未应用于 ZNP 项目。 因此、如果在 定义了 HAL_PA_LNA_CC2592并且 CC2592连接到 CC253x 器件的情况下构建 ZNP 项目、则会出现无线电通信问题。
建议的修复：
将 HAL_PA_LNA_CC2592添加 到 hal_board_cfg.h、如下所示：
//#ifdef HAL_PA_LNA //--- 去掉线--- #if defined HAL_PA_LNA || defined HAL_PA_LNA_CC2592 //++++ 添加此行++++++ #define HAL_Board_PA_LNA_init () st (GPIOPinTypeGPIOOutput (HGM_base、HGM_PIN)；) #else #define HAL_Board_PA_LNA_init () #endif /*---- 射频前端连接初始化--- // //#if defined HAL_PA_LNA || defined HAL_PA_LNA_CC2590 //--- 拆下线--- #if defined HAL_PA_LNA || defined HAL_PA_LNA_CC2590 || defined HAL_PA_LNA_CC2592 //++++++++ 添加以上行++++++++ extern void MAC_RfFrontendSetup (void)； #define HAL_Board_RF_F前端 设置() MAC_RfFrontendSetup() #else #define HAL_Board_RF_FERS_Setup() #endif ( osal_nV_item_init (ZCD_nv_NIB、)#endif // Initialize the NIB Item if (osal_nv_nv_nv_it_nv_nv_inb、nv_nv_inb)= failed_nive_nv_nv_nv_nv_ RET |= NV_NIB_INIT_FAILURE； SIZE =(uint16)(ADDR_Mgr_entry_size * NWK_MAX_ADDRESSES)； status = osal_NV_IT_INIT (ZCD_NV_ADDRMGR、SIZE、NULL)； if (status = NV_IT_UNINIT) ｛ 对于(索引= 0；索引< NWK_MAX_ADDRESSES；index++) ｛ Ctrl[索引]= 0x00； ｝ 对于(index = 0；index < ADDR_Mgr_entry_size；index++) ｛ 偏移= NWK_MAX_ADDRESSES *索引； OSAL_NV_WRITE( ZCD_NV_ADDRMGR，偏移量，NWK_MAX_ADDRESSES，&ctrl )； } }； if (status =nv_Oper_failed) ret |= nv_ADDR_Mgr_init_failure； 返回( ret ); }
此修复程序仅适用于 ZNP 项目、因为家庭自动化示例已经具有此修复程序
22.多属性报告问题
问题描述：
从群集报告多个属性时，所有属性都具有相同的值。
建议的修复：
将 bdb_reporting.c 中的 bdb_RepReport()函数替换为：
静态空 bdb_RepReport( uint8 specificationCLusterEndpointIndex )
{afAddrType_t
dstAddr;
zclReportCmd_t *pReportCmd= NULL；
uint8 i；
bdbReportAttrClusterEndpoint_t* clusterEndpointItem = NULL；
if (specificationCLusterEndpointIndex = BDBREPORTINVALIDINDEX)
{
if (bdb_reportingNextClusterEndpointIndex < bdb_reportingClusterEndpointArrayCount)
｛
clusterEndpointItem =&(bdb_reportingClusterEndpointArray[bdb_reportingNextClusterEndpointIndex])；
｝
｝
否则
｛
clusterEndpointItem =&(bdb_reportingClusterEndpointArray[specificationCLusterEndpointIndex])；
｝
//实际发送报告
if (clusterEndpointItem->consulatedMaxReportInt！= ZCL_Reporting_off && clusterEndpointItem->LinkedIn attendList.numItems)
{
uint8 *pAttrData =空；
uint8 *pAttrDataTemp =空；
dstAddr.addrMode =(afAddrMode_t) AddrNotPresent；
dstAddr.addr.shortAddr = 0；
dstAddr.endpoint = clusterEndpointItem->endpoint;
dstAddr.panId =_NIB.nwkPanId；
//要报告的属性列表
pReportCmd = osal_mem_alloc( sizeof( zclReportCmd_t )+(clusterEndpointItem->attresnationList.numItems* sizeof( zclReport_t ))))；
//属性数据列表
pAttrData = osal_mem_alloc (clusterEndpointItem->attraLinkedIn List.numItems * BDBREPORTING_MAX_ANALOG_ATTR_SIZE)；
if ((pReportCmd！= NULL)&&(pAttrData！= NULL))
｛
pAttrDataTemp = pAttrData；
pReportCmd->numAttr = clusterEndpointItem->AttatLinkedIn List.numItems;
对于( i=0；i<clusterEndpointItem->attatesn LinkedIn List.numItems;++ i )
｛
pReportCmd->attrList[i].attrID = 0xFFFF；
pReportCmd->atList[i].datatype = 0xFF；
pReportCmd->attrList[i].attrData =空；
bdbLinkedIn ListAttrItem_t* attrListItem = bdb_linkedListAttrGetAtIndex(&clusterEndpointItem->atLinkedIn List, i )；
if (attrListItem！=空)
｛
zclAttribute_t atttrRec；
pReportCmd->attrList[i].attrID = attrListItem->data->attrID；
uint8 attrRes = bdb_RepFindAttrEntry (clusterEndpointItem->EndPoint、clusterEndpointItem->cluster、attrListItem->data->attrID、&attrRec)；
if (attrRes == BDBREPORTING_TRUE)
｛
pReportCmd->atList[i].datatype = attrRec.datatype；
pReportCmd->atList[i].attrData = pAttrDataTemp；
//将数据复制到当前属性数据指针
pAttrDataTemp = osal_memcpy (pAttrDataTemp、attrRec.dataPtr、BDBREPORTING_MAX_ANALOG_ATTR_SIZE)；
//更新上次报告的值
if (zclAnalogDataType (attrRec.datatype))
｛
//仅当数据类型为模拟时
OSAL_memset (attrListItem->data->lastValueReported、0x00、BDBREPORTING_MAX_ANALOG_ATTR_SIZE)；
OSAL_memcpy (attrListItem->data->lastValueReported、attrRec.dataPtr、zclGetDataTypeLength (attractRec.datatype))；
｝
}
｝
zcl_SendReportCmd (clusterEndpointItem->endpoint、&dstAddr、
clusterEndpointItem->cluster、pReportCmd、
ZCL_FRAME_SERVER_CLIENT_DIR、BDB_REPORTING_DISABLE_DEFAULT_RSP、bdb_getZCLFrameCounter()；
}
if ((pReportCmd！= NULL))
｛
OSAL_mem_free( pReportCmd )；
}
if ((pAttrData！= NULL))
｛
OSAL_mem_free (pAttrData)；
}
}
23. ZNP 使用错误的项目 ID 初始化 GP 代理表
问题描述：
当 DISABLE_GREENPOWER_BASICE_PROXY 和 ZG_BUIGE_RTR_TYPE 已定义时、ZDApp.c 的 ZDOInitDeviceEx 会使 ZCD_NV_PROXY PROXY 的 NV 项目 ID 开始位置加倍(适用于 ZNP 项目)：
建议的修复：
按如下方式修改 ZDUP.c：
for (i = ZCD_NV_PROVE_TABLE；i <= ZCD_NV_PROVE_Table_end；i++) ｛ status = osal_nv_write(( I )、0、//修改以删除 ZCD_nv_proxy_table_start sizeof (emutyEntry)，&emutyEntry)； if (status！=成功) ｛ 中断； ｝ ｝
24。在器件复位时、帧计数器不会递增
问题描述：
器 件复位时、帧计数器应递增 MAX_NWK_FRAMECOUNTER_Changes + NWK_FRAMECOUNTER_Changes_RESTORE_Delta、以考虑在最后一次 NV 更新和器件复位之间传输的帧。 但是 、ZDUP_RestoreNWKSecMaterial 会尝试写入错误 的 ZCD_NV_EX_NWK_SEC_Material_table、因此无法相应地更新帧计数器。 由于帧计数器不一致、这可能导致 Zigbee 数据包在器件重新启动后被忽略。
建议的修复：
从 ZDUP.c 中修改 ZDUP_RestoreNWKSecMaterial 如下：
//检查我们是否在通用 if (！found) ｛中存储了帧计数器 //如果我们没有在 nv 中找到当前网络，请覆盖通用条目， //这是表中的最后一个条目。 if (nwkSecMaterialDesc.FrameCounter) ｛ UpdateFrameCounter = true； I =(GMAX_NWK_SEC_materie_table_entries - 1)；//添加此行 ｝ ｝
