Other Parts Discussed in Thread: CC2530, Z-STACK
背景信息：
协调器侧使用ZNP模式，版本ZStack-CC2530-2.5.1a。
协调器A：
IEEE MAC地址：0x00124B001BA7704D
channelID:0X1A
PanID:0xA
终端B：
IEEE MAC地址：0x00124B001F1DF13F
channelID:0X1A
PanID:0xA
shortAddr:0x0064
终端C：
IEEE MAC地址：0x00124B0014B3A47D
channelID:0X1A
PanID:0xA
shortAddr:0x0064
CC2530 associatedDevList表和AddrMgrEntry_t表问题：
<1>协调器A与终端B正常启动，按上述参数正常建网入网，终端B与协调器A间可正常发送数据报文（协调器收到终端B的短地址为0x0064）。在协调器侧通过UTIL_ADDRMGR_NWK_ADDR_LOOKUP可以获取到短地址0x0064的终端IEEE MAC地址为终端B的IEEE MAC地址。
<TX>05:09:03.35 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP (0x2741)
NwkAddr: 0x0064
<RX>05:09:03.36 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP_RESPONSE (0x6741)
ExtAddr: 0x00124B001F1DF13F
<2>此时对终端B下电，终端C上电，终端C与协调器A间可正常发送数据报文（协调器收到终端C的短地址为0x0064）。但此时在协调器侧通过UTIL_ADDRMGR_NWK_ADDR_LOOKUP可以获取到短地址0x0064的终端IEEE MAC地址为0（大概率会出现）。
通过Z-tools查询associatedDevList表和AddrMgrEntry_t表记录如下，在终端C直接发送数据0x11 0x22 0x33 0x44 0x55 0x66，协调器侧能收到，显示源短地址为0x0064。具体如下：
Start Time: 2020/5/6 17:21:03
<RX>05:21:25.5 COM35 ZDO_END_DEVICE_ANNCE_IND (0x45C1)
SrcAddr: 0x0064
NwkAddr: 0x0064
IEEEAddr: 0x00124B0014B3A47D
Capabilities: 0x00
<TX>05:21:33.55 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP (0x2741)
NwkAddr: 0x0064
<RX>05:21:33.57 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP_RESPONSE (0x6741)
ExtAddr: 0x0000000000000000
<TX>05:21:35.99 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP (0x2741)
NwkAddr: 0x0064
<RX>05:21:36.01 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP_RESPONSE (0x6741)
ExtAddr: 0x0000000000000000
<TX>05:21:38.57 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP (0x2741)
NwkAddr: 0x0064
<RX>05:21:38.58 COM35 UTIL_ADDRMGR_NWK_ADDR_LOOKUP_RESPONSE (0x6741)
ExtAddr: 0x0000000000000000
<TX>05:23:13.64 COM35 UTIL_ADDRMGR_EXT_ADDR_LOOKUP (0x2740)
ExtAddr: 0x00124B0014B3A47D
<RX>05:23:13.65 COM35 UTIL_ADDRMGR_EXT_ADDR_LOOKUP_RESPONSE (0x6740)
NwkAddr: 0x85A0
<TX>05:23:26.17 COM35 UTIL_ADDRMGR_EXT_ADDR_LOOKUP (0x2740)
ExtAddr: 0x00124B001F1DF13F
<RX>05:23:26.19 COM35 UTIL_ADDRMGR_EXT_ADDR_LOOKUP_RESPONSE (0x6740)
NwkAddr: 0xBE91
<TX>05:23:36.06 COM35 UTIL_ASSOC_COUNT (0x2748)
StartRelation: 0x00
EndRelation: 0x06
<RX>05:23:36.07 COM35 UTIL_ASSOC_COUNT_RESPONSE (0x6748)
Count: 0x0002
<TX>05:23:43.83 COM35 UTIL_ASSOC_FIND_DEVICE (0x2749)
Number: 0x00
<RX>05:23:43.85 COM35 UTIL_ASSOC_FIND_DEVICE_RESPONSE (0x6749)
Device: ..........k....... (0x91, 0xBE, 0x00, 0x00, 0x01, 0x04, 0x01, 0x00, 0x02, 0x01, 0x6B, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
<TX>05:23:51.79 COM35 UTIL_ASSOC_FIND_DEVICE (0x2749)
Number: 0x01
<RX>05:23:51.81 COM35 UTIL_ASSOC_FIND_DEVICE_RESPONSE (0x6749)
Device: .....D....l....... (0xA0, 0x85, 0x01, 0x00, 0x01, 0x44, 0x1A, 0x00, 0x02, 0x01, 0x6C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
<RX>05:24:09.47 COM35 ZB_RECEIVE_DATA_INDICATION (0x4687)
Source: 0x0064
Command: 0x0001
Len: 0x0006
Data: ."3DUf (0x11, 0x22, 0x33, 0x44, 0x55, 0x66)
请问如上associatedDevList表和AddrMgrEntry_t表并没有0x0064短地址记录，为什么协调器能将源短地址0x0064的报文送上来？
我想在协调器侧一直监控源短地址为0x0064的IEEE MAC地址变化情况，如使用UTIL_ADDRMGR_NWK_ADDR_LOOKUP命令，遇见了上述问题，还需要做哪些修改？或者有其它不用主动发包的可行方案（使用ZDO_IEEE_ADDR_REQ的话，协调器会向终端发ZDO包，但终端此时可能处于休眠，无法响应数据）？
