JN5169 Zigbee 3.0 could not join existing Z-Stack 3.0 opened network

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

JN5169 Zigbee 3.0 could not join existing Z-Stack 3.0 opened network

3,024 次查看
cyder_shot
Contributor I

I have been call the steering function,but JN5169 end-device could not join existing opened network,Ubiqua only capture "Becon Request" OTA(over the air) packet,not have the "Association Request" etc.

DBG_vPrintf(TRACE_SWITCH_NODE," Start Steering \n");
sBDB.sAttrib.u32bdbPrimaryChannelSet = BDB_PRIMARY_CHANNEL_SET;
sBDB.sAttrib.u32bdbSecondaryChannelSet = BDB_SECONDARY_CHANNEL_SET;
BDB_eNsStartNwkSteering();

secureCRT control print TRACE out logs,in other word,ZPS_eAplZdoJoinNetwork function return failure value with 0xC2(Request cannot be processed):

APP: Entering bdb_taskBDB
BDB: APP_vGenCallback [0 10]
APP: Entering bdb_taskBDB
BDB: vNsTryNwkJoin - index 0 of 1 Nwks
BDB: Try To join 00124b0009da0ea3 on Ch 11
BDB: ZPS_eAplZdoJoinNetwork failure reason - c2
BDB: Try To join 00124b0009da0ea3 on Ch 11
BDB: ZPS_eAplZdoJoinNetwork failure reason - c2
BDB: No suitable network! Continue Discovery
BDB: Disc on Ch 15 from 0x02108800

Attachments is Ubiqua capture log file

标签 (2)
0 项奖励
回复
9 回复数

2,581 次查看
cyder_shot
Contributor I

Is there any solutions?

0 项奖励
回复

2,581 次查看
patrick_pan
NXP Employee
NXP Employee

Hi, Li

which ZHA version have you checked when FCS fixed to 0xFFFF that can be work with TI GW ?

theoretically, FCS value shouldn't be fixed which violates concept of FCS introduced.

0 项奖励
回复

2,581 次查看
cyder_shot
Contributor I

The JN-AN-1189-ZigBee-HA-Demo for JN5169 was work well with Ti GW Zigbee 3.0 stack with backward Zigbee 2.x version.

The ubiqua capture JN5169 joining network procedure,Beacon Request/Response, Association Request/Response MAC Footer equal 0xFFFF at the same time.

0 项奖励
回复

2,581 次查看
patrick_pan
NXP Employee
NXP Employee

Hi, Li

from your Ubiqua log at line 12, Ti Gateway has issue with wrong Frame Check Sequence as it fixed to 0xffff.

with FCS as 0xffff received by JN5169 , it wouldn't think this is valid Zigbee frame.

0 项奖励
回复

2,581 次查看
cyder_shot
Contributor I

Is it a specific feature in NXP Zigbee 3.0 Stack?

It seems like JN5169 Zigbee 2.x stack(JN-SW-4168) work well with FCS(Frame Check Sequence) equal 0xFFFF and communication  with TI Gateway work well too.

0 项奖励
回复

2,581 次查看
cyder_shot
Contributor I

What's wrong with me?

0 项奖励
回复

2,581 次查看
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Behold,

Could you please compare the status value with this return status?

BDB_E_SUCCESS (Network Steering has been successfully started) * BDB_E_ERROR_IMPROPER_COMMISSIONING_MODE (Network Steering is not enabled) BDB_E_ERROR_COMMISSIONING_IN_PROGRESS (node is already in a commissioning mode) BDB_E_ERROR_INVALID_DEVICE (joining node is a Co-ordinator)

Did you call the BDB_vStart before the BDB_eNsStartNwkSteering?

What is the application note that you are working on?

Mario

0 项奖励
回复

2,581 次查看
cyder_shot
Contributor I

is it have a bug on zigbee stack 3.0?

0 项奖励
回复

2,581 次查看
cyder_shot
Contributor I

I have been disable NTAG feature(NFC TAG), APP_NTAG_ICODE=0 APP_NTAG_AES=0

BDB_vStart() is called by default in vAppMain(app_start_switch.c source file) whenever TASK initialized.

I don't process the BDB_eNsStartNwkSteering() function return status.(Reference other example provide Zigbee 3.0 SDK,this return status may be don't care)

0 项奖励
回复