LAUNCHXL-CC26X2R1: Joined Zigbee device not show on device list.

Hi Peter,

1. You will need to debug the Nwk Srv process from device announcement to device info being added to the database.  You can follow the working x86 PC solution as a reference.

2. It is based off of the Timer clock definitions in OnBoard.h

// Timer clock and power-saving definitions
#ifdef CPU8MHZ
#define TICK_COUNT  125
#define RETUNE_THRESHOLD 250  // 8 Mhz threshold for power saving algorithm
#else
#define TICK_COUNT  250
#define RETUNE_THRESHOLD 500  // 16 Mhz threshold for power saving algorithm
#endif
#define TIMER_DECR_TIME    1  // 1ms - has to be matched with TC_OCC
/* OSAL timer defines */
#define TICK_TIME   1000   /* Timer per tick - in micro-sec */
#if OSAL_TIMER_16_BIT == TRUE
#define OSAL_TIMER  HAL_TIMER_3
#else
#define OSAL_TIMER  HAL_TIMER_1
#endif

Regards,
Ryan

Hi Ryan,

Thanks for feedback.

I found system behavior seems has abnormal symptom ahead of "NS_ADS_NO_RSP" stage after review more debug info. I guess this abnormal might induce later "NS_ADS_NO_RSP" issue. The test step is simple, just as :press allow join from UI console. And the debug log differences as below:

For x86 PC host, I can see ZSTACK_SYS_IDS__RPC_SYS_PROTOBUF CMD: 116. I can find it on ARM host.

To dig more and I found zspbProcessEvent did not receive any SYS_EVENT_MSG for ARM host  test. Details as below:

<<< normal case message log >>>

[11:01:11.437,117] [NWK_MGR/LSTN] UNMSKBL: [EAP101] NWK_MGR_CMD_ID_T__NWK_SET_PERMIT_JOIN_REQ: (sys: 18)
[11:01:11.437,293] [Z_STACK/LSTN] UNMSKBL: [EAP101] ZSTACK_CMD_IDS__ZDO_MGMT_PERMIT_JOIN_REQ: (sys: 49, len=10)
[11:01:11.437,323] [Z_STACK/LSTN] UNMSKBL: [EAP101] Before call processZdoMgmtPermitJoinReq (nwkaddr=fffc, duration=60
[11:01:11.437,335] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in processZdoMgmtPermitJoinReq (send to self)
[11:01:11.441,539] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in ZDP_MgmtPermitJoinReq to send MT_ZDO_MGMT_PERMIT_JOIN_REQ
[11:01:11.441,578] [Z_STACK/LSTN] UNMSKBL: [EAP101] znp_misc sendNPIExpectDefaultStatusZNP: subSys:5, cmdID:36, len::5
[11:01:11.445,323] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in processZdoMgmtPermitJoinReq (sent second)
[11:01:11.445,351] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in ZDP_MgmtPermitJoinReq to send MT_ZDO_MGMT_PERMIT_JOIN_REQ
[11:01:11.445,361] [Z_STACK/LSTN] UNMSKBL: [EAP101] znp_misc sendNPIExpectDefaultStatusZNP: subSys:5, cmdID:36, len::5
[11:01:11.487,140] [Z_STACK/MAIN] UNMSKBL: [EAP101] zspbProcessEvent: SYS_EVENT_MSG...
[11:01:11.487,181] [Z_STACK/MAIN] UNMSKBL: [EAP101] zspbProcessEvent: ZDO_CB_MSG
[11:01:11.487,224] [Z_STACK/MAIN] UNMSKBL: [EAP101] zspbProcessEvent: SYS_EVENT_MSG...
[11:01:11.487,236] [Z_STACK/MAIN] UNMSKBL: [EAP101] zspbProcessEvent: ZDO_CB_MSG
[11:01:11.487,366] [NWK_MGR/HNDL] UNMSKBL: [EAP101] ZSTACK_SYS_IDS__RPC_SYS_PROTOBUF, CMD : 116
[11:01:11.487,398] [NWK_MGR/HNDL] UNMSKBL: [EAP101] ZSTACK_SYS_IDS__RPC_SYS_PROTOBUF, CMD : 116

<<< normal case message log >>>

& 

<<< abnormal case message log >>>

[02:58:04.092,248] [Z_STACK/LSTN] UNMSKBL: [EAP101] znp_misc sendNPIExpectDefaultStatusZNP: subSys:1, cmdID:14, len::1
[02:58:06.599,327] [NWK_MGR/LSTN] UNMSKBL: [EAP101] NWK_MGR_CMD_ID_T__NWK_SET_PERMIT_JOIN_REQ: (sys: 18)
[02:58:06.599,551] [Z_STACK/LSTN] UNMSKBL: [EAP101] ZSTACK_CMD_IDS__ZDO_MGMT_PERMIT_JOIN_REQ: (sys: 49, len=10)
[02:58:06.599,613] [Z_STACK/LSTN] UNMSKBL: [EAP101] Before call processZdoMgmtPermitJoinReq (nwkaddr=fffc, duration=60
[02:58:06.599,650] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in processZdoMgmtPermitJoinReq (send to self)
[02:58:06.604,904] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in ZDP_MgmtPermitJoinReq to send MT_ZDO_MGMT_PERMIT_JOIN_REQ
[02:58:06.604,974] [Z_STACK/LSTN] UNMSKBL: [EAP101] znp_misc sendNPIExpectDefaultStatusZNP: subSys:5, cmdID:36, len::5
[02:58:06.612,013] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in processZdoMgmtPermitJoinReq (sent second)
[02:58:06.612,060] [Z_STACK/LSTN] UNMSKBL: [EAP101] called in ZDP_MgmtPermitJoinReq to send MT_ZDO_MGMT_PERMIT_JOIN_REQ
[02:58:06.612,096] [Z_STACK/LSTN] UNMSKBL: [EAP101] znp_misc sendNPIExpectDefaultStatusZNP: subSys:5, cmdID:36, len::5

<<< abnormal case message log >>>

From my porting steps, two steps are not so straightforward and may be the root cause I think. One is on ARM host environment, the defined values of "PTHREAD_KEYS_MAX" & "PTHREAD_STACK_MIN" are smaller (1/8) than x86 PC host environment. The other is I cannot use (refer: https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1079244/cc2652r-zigbee_3_0_linux_gateway-protobuf-c-compatible-issue-when-porting-to-arm-platform/3995416?tisearch=e2e-sitesearch&keymatch=%2520user%253A292329#3995416) TI pre-built libprotobuf-c library. I build libprotobuf-c library from source codes 

Two questions:

1. Any suggestions for me to fix the issue: "zspbProcessEvent did not receive any SYS_EVENT_MSG after MT_ZDO_MGMT_PERMIT_JOIN_REQ sent out" ? 

2. Is above issue induced from compiled libprotobuf-c ? Does it related to protobuf-c source code version if possible?

Regards,
Peter.

This issue could definitely be related to the protobuf-c build, and I recommend that you use versions as close to the what was used in the original source.  You will need to further debug and resolve any erratic behaviors such as these which arise.  I do not have any suggestions concerning operating outside of the dependencies tested with the out-of-box Zigbee gateway host solution.  Note that BeagleBone Black and Raspberry Pi are two ARM platforms which have been confirmed to work.

Regards,
Ryan

Hi Ryan,

Thanks and two more questions:

1. If "this issue could definitely related to the protobuf-c build", can you give an example to tell more? I want to make sure I am walking on the right direction because I am not sure the operation of protobuf-c & why impact the system behavior.

2. I did search protobuf-c build info before and only find it locates in "Quick Start Guide" doc. However, it does not tell me details. Can you provide TI useful links for source code build steps and source code versions specific for TI Z-Stack Linux Gateway use?

Regards,

Peter.

I just make note here that, I cross compile protobuf-c lib v1.3.1 & v1.2.1 (same as Readme.txt mentioned compiler) to have libprotobuf-c.a & so. But test it failed.

What errors or warnings do you observe while running the setup script?  How do you modify the Makefiles to compensate for your ARM host architecture?

Regards,
Ryan

Hi Ryan,

1. Snipped last log below for setup.sh (modified and rename to eap101_setup.sh) shows OK.

make[1]: Leaving directory '/home/mc_chen/ti/Zigbee_3_0.eap101/source/Projects/zstack/linux/usbreset/project'

Package verification results:
ERROR: 13 warning(s) occured during make
diff /home/mc_chen/ti/Zigbee_3_0.eap101/source/out/content.txt /home/mc_chen/ti/Zigbee_3_0.eap101/source/out/expected_content.txt
mv: target 'directory.tar' is not a directory

OK: RUNTIME package for eap101 created Successfully

SUCCESS: build_all finished.
Entered Precompiled directory.
app/
app/main.bin
misc/
misc/CC2531-GW-ZNP_39203.bin
misc/ota_sample_images/
misc/ota_sample_images/5678-1234-0000BBBB.zigbee
misc/ota_sample_images/5678-1234-0000AAAA.zigbee
protobuf/
protobuf/libprotobuf-c.so.1.0.0
servers/
servers/GATEWAY_SRVR_eap101
servers/track_servers
servers/gateway_config.ini
servers/start_application
servers/sample_app_ota.cfg
servers/NPI_lnx_eap101_server
servers/NWKMGR_SRVR_eap101
servers/config.ini
servers/gateway_config.tlg
servers/ZLSZNP_eap101
servers/OTA_SRVR_eap101
servers/NPI_Gateway.cfg
servers/nwkmgr_config.ini
servers/zigbeeHAgw
tools/
tools/gw_soc_fw_version_query.bin
tools/usbreset.bin
tools/sbl_tool.bin
tools/soc_reset_hold
tools/soc_reset_release
SUCCESS: Extracted binaries
Entered servers/ directory

Make apps exe, copy protobuf files

SUCCESS: Made servers and applications executable
SUCCESS: Made /tools/ folder executable

********** SETUP SUCCESSFUL! **********

--------- Getting Started Tips -----------

Navigate to Node Scripts ==> cd Projects/node

Start Linux Zigbee Gateway and Node.js Zigbee Local Gateway ==> sudo ./start_local.sh

Start Linux Zigbee Gateway and Node.js IBM Gateway ==> sudo ./start_ibm.sh

Start Linux Zigbee Gateway Only ==> sudo ./start_gateway.sh

Kill All Gateways ==> sudo ./end.sh

---------------------------------------------

2. The changed part for Makefile is as below (zstackserverznp as an example):

COMPILO_FLAGS_eap101 = "-O0 -Wall -Wno-unused-but-set-variable $(INCLUDE) $(DEFINES) -include ../hal/hal_types.h -include f8wConfig.h -D__EAP101__ -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a"

Regards,

Peter.

Thank you for sharing.  It's difficult to gather any further information from the build log since there are only warnings.  As we have been discussing, there could still be an inconsistency between ARM host and protobuf build which causes communication to fail.  I don't know enough about your specific ARM host to provide further commentary on the compile flags.

Regards,
Ryan