Zigbee router generates ZB_NWK_SIGNAL_NO_ACTIVE_LINKS_LEFT signal all the time

Hello everyone,

I'm encountering an issue with my Zigbee network that I hope someone can assist me with. Despite my efforts, I haven't been able to find a resolution.

I'm using two nrf52840 DK boards, one serving as the coordinator and the other as a router. Initially, the router successfully joins the network, but I consistently receive the ZB_NWK_SIGNAL_NO_ACTIVE_LINKS_LEFT signal thereafter. Strangely, the state signal appears to be normal. I've attached a Wireshark log along with logs from both the router and coordinator for further reference.

Any insights or assistance on resolving this would be greatly appreciated.

Thank you,

Julen

*** Booting nRF Connect SDK v2.5.1 ***
[00:00:00.012,420] <err> main: RESET
[00:00:00.012,451] <dbg> main: get_reset_reason: Reset cause is: RESET_PIN

[00:00:00.012,481] <inf> nvram_app: Page info: size 4096, start offset 1024000

[00:00:00.012,542] <dbg> fs_nvs: nvs_recover_last_ate: Recovering last ate from sector 0
[00:00:00.020,568] <inf> fs_nvs: 3 Sectors of 4096 bytes
[00:00:00.020,599] <inf> fs_nvs: alloc wra: 0, fc8
[00:00:00.020,599] <inf> fs_nvs: data wra: 0, 2c
[00:00:00.020,629] <inf> nvram_app: NVRAM initialized

[00:00:00.020,690] <inf> zb_conf: NVRAM first id is correct

[00:00:00.020,751] <dbg> zb_conf: zb_conf_read_from_nvram: Extended PAN ID:
                                  88 88 00 00 00 00 00 00                          |........
[00:00:00.020,751] <wrn> zb_conf: Reading Node Identifier from NVRAM

[00:00:00.020,812] <wrn> zb_conf: Node Identifier:

[00:00:00.020,812] <wrn> zb_conf: Size of Node Identifier: 21

[00:00:00.020,874] <inf> zb_conf: Node Identifier: TCU_SUNNER_ID_198

[00:00:00.020,935] <dbg> zb_conf: zb_get_mac_addr_high: Zigbee long address:
[00:00:00.020,965] <dbg> zb_conf: zb_get_mac_addr_high: MAC address:
                                  a2 46 b3 cc 1f 36 ce f4                          |.F...6..
[00:00:00.020,996] <dbg> zb_conf: zb_get_mac_addr_high: MAC address:
                                  1f 36 ce f4                                      |.6..
[00:00:00.021,026] <dbg> zb_conf: zb_get_mac_addr_low: Zigbee long address:
[00:00:00.021,057] <dbg> zb_conf: zb_get_mac_addr_low: MAC address:
                                  f4 ce 36 1f cc b3 46 a2                          |..6...F.
[00:00:00.021,087] <dbg> zb_conf: zb_get_mac_addr_low: MAC address:
                                  a2 46 b3 cc                                      |.F..
[00:00:00.021,301] <inf> main: Router started successfully
[00:00:00.703,521] <wrn> main: SIGNAL 23 , state not OK
[00:00:00.703,552] <inf> zigbee_app_utils: Production configuration is not present or invalid (status: -1)
[00:00:00.704,132] <wrn> main: SIGNAL 1 , state OK
[00:00:00.704,162] <wrn> main: Parent Node: 0xffff
[00:00:00.704,193] <inf> zigbee_app_utils: Zigbee stack initialized
[00:00:00.710,998] <wrn> main: SIGNAL 5: Device started for the first time after the NVRAM erase
[00:00:00.710,998] <inf> zigbee_app_utils: Device started for the first time
[00:00:00.711,029] <inf> zigbee_app_utils: Start network steering
[00:00:00.711,059] <inf> zigbee_app_utils: Started network rejoin procedure.
[00:00:10.304,534] <dbg> main: diagnostic_zigbee_info: Zigbee application joined the network: bellow some info:

[00:00:10.304,565] <dbg> main: diagnostic_zigbee_info: zigbee shrot addr:  0xa1ee

[00:00:10.304,595] <dbg> main: diagnostic_zigbee_info: Extended PAN ID:
                               00 00 00 00 00 00 88 88                          |........
[00:00:10.304,626] <dbg> main: diagnostic_zigbee_info: zigbee role router

[00:00:10.304,626] <dbg> main: diagnostic_zigbee_info: zigbee channel: 23

[00:00:10.974,975] <wrn> main: SIGNAL 54 , state OK
[00:00:10.974,975] <wrn> main: Parent Node: 0x0000
[00:00:10.975,006] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:00:11.435,241] <wrn> main: SIGNAL 54 , state OK
[00:00:11.435,272] <wrn> main: Parent Node: 0x0000
[00:00:11.435,302] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:00:11.438,323] <wrn> main: SIGNAL 10 , state OK
[00:00:11.438,354] <wrn> main: Parent Node: 0x0000
[00:00:11.438,385] <wrn> main: Device is encountering issues during steering.
[00:00:11.438,598] <inf> zigbee_app_utils: Joined network successfully (Extended PAN ID: 0000000000008888, PAN ID: 0x1226)
[00:00:11.438,598] <inf> zigbee_app_utils: Network rejoin procedure stopped.
[00:01:00.002,471] <dbg> main: display_counters: APS RX COUNTERS: Total 0, Binary 0, Commis 0
[00:01:00.002,502] <dbg> main: display_counters: Uart frames: Tx 0, Rx 0
[00:01:10.901,214] <wrn> main: SIGNAL 24 , state OK
[00:01:10.901,245] <wrn> main: Parent Node: 0x0000
[00:01:10.901,275] <wrn> main: Device is encountering issues during steering.
[00:01:10.901,275] <wrn> zigbee_app_utils: Parent is unreachable
[00:01:25.868,591] <wrn> main: SIGNAL 24 , state OK
[00:01:25.868,621] <wrn> main: Parent Node: 0x0000
[00:01:25.868,621] <wrn> main: Device is encountering issues during steering.
[00:01:25.868,652] <wrn> zigbee_app_utils: Parent is unreachable
[00:01:40.828,735] <wrn> main: SIGNAL 24 , state OK
[00:01:40.828,765] <wrn> main: Parent Node: 0x0000
[00:01:40.828,796] <wrn> main: Device is encountering issues during steering.
[00:01:40.828,796] <wrn> zigbee_app_utils: Parent is unreachable
[00:01:55.835,479] <wrn> main: SIGNAL 24 , state OK
[00:01:55.835,510] <wrn> main: Parent Node: 0x0000
[00:01:55.835,510] <wrn> main: Device is encountering issues during steering.
[00:01:55.835,540] <wrn> zigbee_app_utils: Parent is unreachable
[00:02:00.004,760] <dbg> main: display_counters: APS RX COUNTERS: Total 0, Binary 0, Commis 0
[00:02:00.004,821] <dbg> main: display_counters: Uart frames: Tx 0, Rx 0
[00:02:10.808,898] <wrn> main: SIGNAL 24 , state OK
[00:02:10.808,929] <wrn> main: Parent Node: 0x0000
[00:02:10.808,929] <wrn> main: Device is encountering issues during steering.
[00:02:10.808,959] <wrn> zigbee_app_utils: Parent is unreachable
[00:02:25.789,459] <wrn> main: SIGNAL 24 , state OK
[00:02:25.789,489] <wrn> main: Parent Node: 0x0000
[00:02:25.789,489] <wrn> main: Device is encountering issues during steering.
[00:02:25.789,520] <wrn> zigbee_app_utils: Parent is unreachable
[00:02:40.772,369] <wrn> main: SIGNAL 24 , state OK
[00:02:40.772,430] <wrn> main: Parent Node: 0x0000
[00:02:40.772,430] <wrn> main: Device is encountering issues during steering.
[00:02:40.772,460] <wrn> zigbee_app_utils: Parent is unreachable
[00:02:55.740,661] <wrn> main: SIGNAL 24 , state OK
[00:02:55.740,692] <wrn> main: Parent Node: 0x0000
[00:02:55.740,692] <wrn> main: Device is encountering issues during steering.
ZB_NWK_SIGNAL_NO_ACTIVE_LINKS_LEFT_LOG.pcapng
W: JULEN ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED

I: Device authorization event received (short: 0xd239, long: f4ce361fccb346a2, authorization type: 0, authorization status: 0)
I: Unimplemented signal (signal: 54, status: 0)
I: Network steering finished
I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.5.1 ***
I: Starting ZBOSS Coordinator example
I: ZBOSS Coordinator example started
W: JULEN ZB_ZDO_SIGNAL_PRODUCTION_CONFIG_READY

I: Production configuration is not present or invalid (status: -1)
W: JULEN ZB_ZDO_SIGNAL_SKIP_STARTUP

I: Zigbee stack initialized
I: Device started for the first time
I: Start network formation
I: Unimplemented signal (signal: 54, status: 0)
W: JULEN ZB_BDB_SIGNAL_FORMATION

I: Network formed successfully, start network steering (Extended PAN ID: 0000000000008888, PAN ID: 0x1226)
I: Unimplemented signal (signal: 54, status: 0)
I: Allow pre-Zigbee 3.0 devices to join the network
I: Network steering started
W: JULEN ZB_NWK_SIGNAL_DEVICE_ASSOCIATED

W: Obsolete signals, used for pre-R21 ZBOSS API. Ignore
W: JULEN ZB_ZDO_SIGNAL_DEVICE_UPDATE

I: Device update received (short: 0x5710, long: f4ce361fccb346a2, status: 1)
W: JULEN ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED

I: Device authorization event received (short: 0x5710, long: f4ce361fccb346a2, authorization type: 0, authorization status: 0)
I: Unimplemented signal (signal: 54, status: 0)
I: Network steering finished
I: Top level commissioning restated
I: Unimplemented signal (signal: 54, status: 0)
I: Allow pre-Zigbee 3.0 devices to join the network
I: Network steering started
W: JULEN ZB_NWK_SIGNAL_DEVICE_ASSOCIATED

W: Obsolete signals, used for pre-R21 ZBOSS API. Ignore
W: JULEN ZB_ZDO_SIGNAL_DEVICE_UPDATE

I: Device update received (short: 0xa1ee, long: f4ce361fccb346a2, status: 1)
W: JULEN ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED

I: Device authorization event received (short: 0xa1ee, long: f4ce361fccb346a2, authorization type: 0, authorization status: 0)
I: Unimplemented signal (signal: 54, status: 0)
I: Network steering finished
I: Top level commissioning restated
I: Unimplemented signal (signal: 54, status: 0)
I: Allow pre-Zigbee 3.0 devices to join the network
I: Network steering started
W: JULEN ZB_NWK_SIGNAL_DEVICE_ASSOCIATED

W: Obsolete signals, used for pre-R21 ZBOSS API. Ignore
W: JULEN ZB_ZDO_SIGNAL_DEVICE_UPDATE

I: Device update received (short: 0xa1ee, long: f4ce361fccb346a2, status: 1)
W: JULEN ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED

I: Device authorization event received (short: 0xa1ee, long: f4ce361fccb346a2, authorization type: 0, authorization status: 0)
I: Unimplemented signal (signal: 54, status: 0)
I: Network steering finished

Parents
  • Hello,

    Sorry for the late reply. I was out of office a few days last week. 

    If you compare the log to the sniffer trace, about where in the sniffer trace does the "Parent is unreachable" messages start to appear? 

    I'm using two nrf52840 DK boards

    Are those two devices the only devices in your network?

    Best regards,

    Edvin

  • Hello Edvin,

    After reviewing the log and sniffer trace, it appears that the "Parent is unreachable" messages start to appear around package number 170. In package number 170, you can observe the router (f4:ce:36:1f:cc:b3:46:a2) joining the coordinator with the 0xa1ee short address. the exact moment when the "Parent is unreachable" message begins is somewhat indeterminate, as it seems to occur automatically following the initial connection.

    The test was conducted on my desk with one nrf52840 DK board as coordinator and one EV-BT840E-p, evaluation board for BT840E as router. These were the only devices in the network during the test.

    Thank you for your support throughout this process.

    Best regards,

    Julen

  • Hello Julen,

    Does it only happen with the combination 1x nRF52840DK and 1x EV-BT840E-p evaluation board?

    Does it also happen if you run 2x nRF52840DKs one programmed as the coordinator as before, and one programmed with a similar application 

    I am not saying that you can't use the BT840E device, but as part of the debugging process, it could give some pointers as to what triggers the issue. 

    BR,

    Edvin

Reply
  • Hello Julen,

    Does it only happen with the combination 1x nRF52840DK and 1x EV-BT840E-p evaluation board?

    Does it also happen if you run 2x nRF52840DKs one programmed as the coordinator as before, and one programmed with a similar application 

    I am not saying that you can't use the BT840E device, but as part of the debugging process, it could give some pointers as to what triggers the issue. 

    BR,

    Edvin

Children
  • Hello Edvin,

    Thank you for your assistance.

    I need to correct myself; in the test I conducted, I didn't use the nRF52840 as a coordinator. Instead, I utilized the Panasonic PAN1780_EVB. Today, I conducted some additional tests that might provide some insight.

    Initially, I kept the PAN1780 as the coordinator and added two routers (nRF52840_DK and EV-BT840E-p), both of which successfully joined the coordinator. I've attached the file "joined OK.zip" for reference.

     joined OK.zip

    However, when I removed the nRF52840DK from the network and restarted the PAN1780 coordinator with only the EV-BT840E-p as a router, the problem persisted. You can find the details in the attached file "parent_unreachable.zip".
    parent_unreachable.zip

    In my experience thus far, transitioning a router from one network/coordinator to another has been somewhat inconsistent. Sometimes, it joins smoothly, while other times it takes longer or requires multiple flash memory erasures to proceed with testing. This variability can pose challenges for our product, and we aim to gain better control over this process.

    Is this issue unique to my current case? Have you encountered similar challenges before?

    Best regards,

    Julen

  • Ok, so when you remove the nRF52840DK, then both the coordinator and the EV-BT840E are factory reset? Or does one, or both, contain old network data? I assume they are within radio range of one another? Or are they far apart?

    BR,
    Edvin

  • Hello,

    All devices are currently within radio range. Every time we restart the device, we clear out old factory data using zb_set_nvram_erase_at_start(ZB_TRUE). I'd like to confirm if this approach aligns with best practices.

    Best regards,

    Julen

  • Hello Julen,

    And are all the devices reset at once? If they are reset one by one, it could lead to some weird behavior, if one device is reset, but the other device thinks it is still part of the network, perhaps starting the onboarding process for the newly reset device, and then you reset the other device as well. In this case, the device that was reset first will be halfway through the commissioning process, and the device reset last will not know about this.

    Can you try to erase all the devices (nrfjprog --eraseall) and then re-program them? Does it behave the same then? As long as all the devices are erased at the same time, we can rule out that there is some old network data in the loop.

    Also, properly erasing the device using a programmer can rule out whether the zb_set_nvram_erase_at_start() completes successfully or not. For debugging purposes.

    When you get this all working properly, it would be sufficient to halt all the devices before you start resetting them (nrfjprog --halt)

    Best regards,

    Edvin

  • Dear Edvin,

    I've identified the error. The problem arose when trying to connect a router with encryption disabled to an encrypted network. In the past, encountering this issue would result in the router leaving the network with some messagges related to transportation key  However, this time, that didn't appear so I didn't realize the problem could be related to encryption.

    I truly appreciate your efforts to help resolve this issue.

    Best regards,

    Julen

Related