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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

3,011 Views
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

Labels (2)
0 Kudos
Reply
9 Replies

2,568 Views
cyder_shot
Contributor I

Is there any solutions?

0 Kudos
Reply

2,568 Views
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 Kudos
Reply

2,568 Views
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 Kudos
Reply

2,568 Views
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 Kudos
Reply

2,568 Views
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 Kudos
Reply

2,568 Views
cyder_shot
Contributor I

What's wrong with me?

0 Kudos
Reply

2,568 Views
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 Kudos
Reply

2,568 Views
cyder_shot
Contributor I

is it have a bug on zigbee stack 3.0?

0 Kudos
Reply

2,568 Views
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 Kudos
Reply