ZX_genericapp專案ED使用AF_DATAREQUEST出現大量AF_INCOME事件.

Hunter Wang

Expert 1730 points

Other Parts Discussed in Thread: SYSCONFIG, Z-STACK

HI TI

在測試 genericapp 時出現一個很奇怪的現象,

現在是大概一個協調器對五個ED
(二塊原廠板,三塊外購模組,協調器也是外購模組)

本來是ED有做一個定時事件五秒回傳一個訊息
(訊息裡面有ED自身短位址跟父節點短位址)
回協調器,那大概應該只會有一二筆AF_INCOME事件嘛,
(因為之前在2538試的時候是這樣子.)

但是現在在2652R試時,出現回傳一二筆正常DATA的傳完了.
後面會再出現一百多筆的DATA傳送??!!
因為在OLED上會看到AF_INCOME事件一直被觸發
(AF_INCOME事件那邊有放進來一次事件就COUNTER加一)

數目高達一百多次!!!
而且是協調器和ED都有一百多次的AF_INCOME事件!!
(看SNIFFER,看起來像是協調器和ED在互傳.一去一回了一百多次)

可是沒有發這麼多呀??

AF_DATAREQUEST明明只CALL了一次,卻在發了一次之後
又多發了一百多次不知道是在幹嘛的訊息,
但為什麼要做目前還沒有查到.

而且不只外購模組,連原廠板也會出現!!
但就是會有一到二個ED會出現這樣子的大量傳收的狀況.

想問下您有沒有遇到這樣子的狀況

謝謝.

5 年多前

0 Viki Shi 5 年多前

TI__Guru**** 188340 points

“AF_DATAREQUEST明明只CALL了一次,卻在發了一次之後，又多發了一百多次不知道是在幹嘛的訊息,”

是不是信号不好重发了，不过一百多次也太多了吧。。。有没有抓包文件？

0 Hunter Wang 5 年多前回复 Viki Shi

Expert 1730 points

HI VIKI

這個

5D98.psd

0 Hunter Wang 5 年多前回复 Viki Shi

Expert 1730 points

HI VIKI
剛有試一下拿2538來做COOR
配二個2538做ED+三個2652R做ED
反而正常噯??沒有再大量傳送了.

好奇怪.

0 YiKai Chen 5 年多前回复 Hunter Wang

Guru 109510 points

你的抓包檔需要network key才能看到你送的data ,但感覺是你應用程序的問題造成一直大量傳送

0 Hunter Wang 5 年多前回复 YiKai Chen

Expert 1730 points

HI YK

1: "要network key才能看到你送的data"

network key 是指??? 因為都是SDK原始產出的專案檔.
是在SYSCONFIG裡面設定的那個 ??
我也在好奇,這個SNIFFER怎麼用這麼久,
都看不到自己送出來的東西

2:"感覺是你應用程序的問題"

這個還在抓,因為昨晚拿了2538再做了一下這樣子的測試:

協調器 ZC_GAPP(2652R+SDK) X 1 配合 2 顆 ZED_GAPP(2538+ZSTACK3.0.2) : OK

協調器 ZC_GAPP(2538+ZSTACK3.0.2) X 1 配合

3顆(ZED_GAPP(2652R+SDK) + 2顆 ZD_GAPP(2538+ZSTACK3.0.2) : OK

以上兩個組合都沒有再大量的AF_IMCOME事件發生.

奇怪.

0 YiKai Chen 5 年多前回复 Hunter Wang

Guru 109510 points

SYSCONFIG裡面設定的的那個是TC link key

0 Hunter Wang 5 年多前回复 YiKai Chen

Expert 1730 points

HI YK

那network key 是指???

謝謝.

0 YiKai Chen 5 年多前回复 Hunter Wang

Guru 109510 points

Network key是用來加密Zigbee 封包的key、一般是入網的時候coordinator 先用tc link key加密network key傳給入網設備

0 Hunter Wang 5 年多前回复 YiKai Chen

Expert 1730 points

HI YK
這個:
/* Default security key. */
#ifndef DEFAULT_KEY
#define DEFAULT_KEY {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}
#endif

0 YiKai Chen 5 年多前回复 Hunter Wang

Guru 109510 points

使能TC Link Key後Z-Stack內部會隨機產生network key,不是用DEFAULT_KEY,你抓包的時候只要有設備入網交換key的過程,就可以抓到network key

0 Hunter Wang 5 年多前回复 YiKai Chen

Expert 1730 points

HI YK

現在先用TRY ERROR的方式, 先比較和Z-STACK 3.0.2的ZC協調器差在那裡.

結果是:zcl_ProcessMessageMSG()??

先把這個先蓋掉就不會有大量AF_INCOME事件發生了.

順序是:

1:if( (pMsg = (zstackmsg_genericReq_t*) OsalPort_msgReceive( appServiceTaskId )) != NULL) -->

2:zclGenericApp_processZStackMsgs(pMsg); -->

3:zclGenericApp_processAfIncomingMsgInd( &(pInd->req) ); -->
(我在這裡拿到傳進來的訊息.)

4:zcl_ProcessMessageMSG(&afMsg); --> ??
結果是這裡引發大量AF_INCOME事件??

奇怪.現在還在查.

0 Hunter Wang 5 年多前回复 Hunter Wang

Expert 1730 points

HI YK

查了以後發現這個好像是拿來專門
處理ZCL格式的MESSAGE.
好像就是你說的ZCL方式來收發.
所以SDK預設用你說的ZCL方法??
不是用AF_DATAREQUEST了?

所以我自己亂編的DATA格式,丟進這個函式
會觸發一些非預期的事件.

謝謝.

0 YiKai Chen 5 年多前回复 Hunter Wang

Guru 109510 points

是.SDK預設用ZCL方法收發

Zigbee 和 Thread

Zigbee 和 Thread 论坛

ZX_genericapp專案ED使用AF_DATAREQUEST出現大量AF_INCOME事件.