• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 55 subscribers
  • Views 501 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

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

LAUNCHXL-CC26X2R1: Re-start zigbeeHAgw (& start_application) scripts makes ZED cannot join network.

user4650693
Intellectual 440 points
Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: Z-STACK

I use CC2652R1 LaunchPad as golden ZED which flashed with zed_temperaturesensor (5_20_00_52) build.

The Zigbee Linux Gateway I download is Zigbee_3_0_Linux_Gateway_1_0_1.run. I have build native on x86 PC host and talks to another CC2652R1 LaunchPad flashed with standard znp FW via USB.

Run with two script files (zigbeeHAgw & start_application) and test ZED join network successfully.

However, when I exits and re-start two scripts again, ZED cannot join without unplug USB. It becomes OK when unplug USB & run again.

Snipped logs are listed below for normal and abnormal cases:

=== Normal case ===

[15:03:01.890,776] [Z_STACK/LSTN] UNMSKBL: #Peter# zstackpb zspbHandlePbCb: subsystemID:0x31, cmdId:0x8 # <= "ZSTACK_CMD_IDS__SYS_NWK_INFO_READ_REQ"
[15:03:01.890,872] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:03:01.890,905] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:80 #
[15:03:01.890,938] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:80 OK. #
[15:03:01.895,052] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x50, length: 24 <= NPI recognize this frame!
[15:03:20.939,450] [Z_STACK/LSTN] UNMSKBL: #Peter# zstackpb zspbHandlePbCb: subsystemID:0x31, cmdId:0x43 # <= "ZSTACK_CMD_IDS__ZDO_MGMT_PERMIT_JOIN_REQ"
[15:03:20.939,538] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:03:20.939,570] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:80 #
[15:03:20.939,603] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:80 OK. #
[15:03:20.943,672] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x50, length: 24 <= NPI recognize this frame!
[15:03:20.943,854] [Z_STACK/LSTN] UNMSKBL: #Peter# znp_misc sendNPIExpectDefaultStatusZNP: subSys:0x5, cmdID:0x36, len::5
[15:03:20.943,931] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:03:20.943,960] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:54 #
[15:03:20.943,985] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:54 OK. #
[15:03:20.947,575] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x36, length: 1 <= NPI recognize this frame!
[15:03:20.947,724] [Z_STACK/LSTN] UNMSKBL: #Peter# zstackpb processZdoMgmtPermitJoinReq: duration:60 #
[15:03:20.947,746] [Z_STACK/LSTN] UNMSKBL: #Peter# znp_misc sendNPIExpectDefaultStatusZNP: subSys:0x5, cmdID:0x36, len::5
[15:03:20.947,811] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:03:20.947,838] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:54 #
[15:03:20.947,874] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:54 OK. #
[15:03:20.948,437] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x45, Cmd ID: 0xB6, length: 3 <= NPI found Cmd ID: 0xB6 (RSP)
[15:03:20.948,578] [Z_STACK/HNDL] UNMSKBL: #Peter# znp_misc handleAsyncMsgs: subSys:5, cmdID:0xb6 #
...

=== Abnormal case ===

[15:06:39.178,873] [Z_STACK/LSTN] UNMSKBL: #Peter# zstackpb zspbHandlePbCb: subsystemID:0x31, cmdId:0x8 # <= "ZSTACK_CMD_IDS__SYS_NWK_INFO_READ_REQ"
[15:06:39.179,034] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:06:39.179,070] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:80 #
[15:06:39.179,107] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:80 OK. #
[15:06:39.183,141] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x50, length: 24 <= NPI recognize this frame!
[15:06:56.353,052] [Z_STACK/LSTN] UNMSKBL: #Peter# zstackpb zspbHandlePbCb: subsystemID:0x31, cmdId:0x43 # <= "ZSTACK_CMD_IDS__ZDO_MGMT_PERMIT_JOIN_REQ"
[15:06:56.353,144] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:06:56.353,179] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:80 #
[15:06:56.353,210] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:80 OK. #
[15:06:56.357,287] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x50, length: 24 <= NPI recognize this frame!
[15:06:56.357,460] [Z_STACK/LSTN] UNMSKBL: #Peter# znp_misc sendNPIExpectDefaultStatusZNP: subSys:0x5, cmdID:0x36, len::5
[15:06:56.357,532] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:06:56.357,559] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:54 #
[15:06:56.357,584] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:54 OK. #
[15:06:56.360,318] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x36, length: 1 <= NPI recognize this frame!
[15:06:56.360,463] [Z_STACK/LSTN] UNMSKBL: #Peter# zstackpb processZdoMgmtPermitJoinReq: duration:60 #
[15:06:56.360,487] [Z_STACK/LSTN] UNMSKBL: #Peter# znp_misc sendNPIExpectDefaultStatusZNP: subSys:0x5, cmdID:0x36, len::5
[15:06:56.360,548] [NPISRVR/MAIN] UNMSKBL: #Peter# Receive message...
[15:06:56.360,576] [NPISRVR/MAIN] UNMSKBL: #Peter# NPI_UART_SendSynchData: cmdId:54 #
[15:06:56.360,600] [NPISRVR/MAIN] UNMSKBL: #Peter# npi_sendframe: subSys:37, cmdId:54 OK. #
[15:06:56.363,693] [NPISRVR/U_RX] UNMSKBL: #Peter# [UART] npi_procframe, subsys: 0x65, Cmd ID: 0x36, length: 1 <= No RSP...

Some symptoms listed below: 

1. The Assoc bit within superframe is not set correctly. It shows value 0 not value 1 for the second-time test. (note: other bits are same as first-time test)

2. For last "NPISRVR/U_RX" log of two cases, their subSys values are different.

Two questions:

1. Do I need extra steps when scripts re-start without unplug USB or re-start znp FW to make it normal?

2. How to interpret subSys?

Regards,

Peter.

  • 0
    TI__Guru**** 219007 points

    Hi Peter,

    Please let me know whether any of the following E2E posts resolve your issue:

    https://e2e.ti.com/f/1/t/850677 
    https://e2e.ti.com/f/1/t/938713 
    https://e2e.ti.com/f/1/t/940644 
    https://e2e.ti.com/f/1/t/1024945 

    At any rate, several are good improvements to implement on your Zigbee gateway host.

    The subsystemId is a combination of RPC Command Field type and subsystem, which are defined in hal_rpc.h 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 440 points

    Hi Ryan,

    Thanks for feedback. I have tentative comments below after checking above posts you provided:

    - e2e.ti.com/.../850677 : GW initialize failed. Not my case.
    - e2e.ti.com/.../938713 : Z-Stack related. My issue should be happen in-between NPI vs. znp FW (due to no 0xB6 RSP)?
    - e2e.ti.com/.../940644 : SOC_RESET_REQUIRED settings. x86 set to 0 for my case. Should be OK.
    - e2e.ti.com/.../1024945 pairing issue through route. Not my case. I am testing ZED to Coordinator case.

    I tested with "soft reset" which re-start servers too. In this case I can re-join ZED. So my question is:

    Soft reset will send CMD: "NWK_MGR_CMD_ID_T__NWK_ZIGBEE_SYSTEM_RESET_REQ". What's the command differences between soft reset and re-start zigbeeHAgw script in term of znp FW? Or advise where can I check for?

    BTW, there are two hal_rpc.h files (./Projects/zstack/linux/srvwrapper/hal_rpc.h & ./Projects/zstack/linux/RemoTI-Linux-master/Projects/tools/LinuxHost/ipclib/common/hal_rpc.h). But these two have some minor differences. I think we should use "./Projects/zstack/linux/srvwrapper/hal_rpc.h" for all server codes including NPI server. Am I right?

    Regards,

    Peter.

  • 0 in reply to user4650693
    TI__Guru**** 219007 points

    A soft reset will cause a software reset command of the ZNP firmware, whereas restarting the zigbeeHAgw script only affects the host software operation.

    You would use the srvwrapper version as RPC_SYS_PROTOBUF is commonly referenced by other source files.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 440 points

    Hi Ryan,

    For soft reset test, I check with zigbeeHAgw and found it will wait for NETWORK MANAGER to stop as in "wait $NETWORK_MGR_PID && exit_code=$?". The zigbeeHAgw will call stop_all when I set soft reset command. So the soft reset will also stop all servers first. However, I found the return code is 0 not 2 on x86 PC host environment. As the return code is 0, zigbeeHAgw will call start_all (& hw_reset_soc) anyway. Three questions:

    1. It should have return code 2 (NWKMGR_SOFT_RESET_CODE), but I got debug value 0. And where to set the return value of NETWORK MANAGER?

    2. What's the purpose of variable NWKMGR_RESTART_FLAG? 

    3. What's the purpose for hw_reset_soc( )? Is it a generic code or platform dependent?

    Regards,

    Peter.

  • 0 in reply to user4650693
    TI__Guru**** 219007 points

    1. That is an unexpected exit code, which could imply that the NWKMGR or other network server has already been exited.

    2. It can be echoed on start_netmgr so that users know the restart reason. https://e2e.ti.com/f/1/t/940644 

    3. This is used for a hardware reset, i.e. holding the RST pin low then releasing it.  soc_reset_hold/soc_reset_release can be platform dependent depending on USB reset requirements.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 440 points

    Hi Ryan,

    Thanks. I will investigate more on return code issue when do soft reset later. The symptom is: I got value 2 on my ARM platform but got value 0 on PC x86.

    My last question is: why I re-start manually (re-start zigbeeHAgw script and start_application script) makes allow join failure? Refer to soft reset, it is OK for allow join again. Its steps can be decomposed into three steps: stop_all, hw_reset_soc, and start_all. The difference between "soft reset" and "re-start manually" is only hw_reset_soc. Am I right?  As x86 did nothing for hw_reset_soc. I am confused.

    Regards,

    Peter.

  • 0 in reply to user4650693
    TI__Guru**** 219007 points

    In zigbeeHAgw, SOC_RESET_REQUIRED is set to zero for x86.  You can change this to force the hw_reset_soc on start_all.  I would recommend resetting the ZNP MCU to allow for synchronization between systems.  Please refer to this E2E post for a known issue regarding permit join failure due to ZDO endpoint deletion from the gateway.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 440 points

    Hi Ryan,

    I think you mis-understand my question. The platform I test is x86 PC and I am asking second-time re-start issue.

    For first-time start-up which run manually with zigbeeHAgw and start_application. SOC_RESET_REQUIRED is set to zero. Join test is fine.

    For second-time, There are two ways: one is "manually kill zigbeeHAgw and start_application and re-start again"; the other is "using soft reset command".

    For "manually kill zigbeeHAgw and start_application and re-start again", the SOC_RESET_REQUIRED is value zero. But for "using soft reset command", the SOC_RESET_REQUIRED is set to value one, which will call hw_reset_soc. And hw_reset_soc do nothing for x86 now.

    I am confused with the test result: "manually kill zigbeeHAgw and start_application and re-start again" way, join test is not OK, but "using soft reset command" way, join test is fine.

    Regards,

    Peter.

  • +1 in reply to user4650693
    TI__Guru**** 219007 points

    Perhaps the hw_reset_soc incurs a delay that is needed for the ZNP to properly sync with the application after the restart, otherwise I do not understand how to address this behavior and suggest you implement the solution which is known to work.

    Regards,
    Ryan