RE: Zigbee Sleepy End Device Immediately Sleeps after Joining Network

Patrick — Tue, 02 Apr 2019 12:53:14 GMT

It turns out that I had apparently not copied everything needed from the Thread and Zigbee SDK into the VisualGDB folder structure. I originally only copied the folders that were obviously added by the Thread and Zigbee SDK but clearly missed some files that had been changed from the standard SDK. Everything is now functioning as expected.

RE: Zigbee Sleepy End Device Immediately Sleeps after Joining Network

Jørgen Holmefjord — Mon, 01 Apr 2019 14:33:43 GMT

Great, let me know if you need any more follow-up from our side.

RE: Zigbee Sleepy End Device Immediately Sleeps after Joining Network

Patrick — Mon, 01 Apr 2019 03:13:58 GMT

I have done quite a bit more digging on this problem this weekend and think I am getting close to a solution. I modified the makefile included with the light switch example and was able to produce a properly functioning firmware using my project source files from VisualGDB. Unfortunately I haven’t gotten VIsualGDB itself to produce a properly functioning firmware but feel comfortable saying that this is a tooling problem. As such, I have a case open with their support to hopefully find a solution.

RE: Zigbee Sleepy End Device Immediately Sleeps after Joining Network

Patrick — Sat, 30 Mar 2019 03:01:45 GMT

Hi Jorgen,

I had not taken the time to test out the light_switch example but have now taken the time to. The good news is that the light_switch example works as expected (using SES). One of the first things I noticed between my firmware and the light_switch example is how when in "sleepy mode", the "CAN_SLEEP..." event is fired in between each "Failed to join network" event, unlike my firmware.

After a lot more digging I thinking that the issue lies somewhere in my toolchain and the compiled output. I have been using C++ and VisualGDB (Visual Studio addin, GCC 7.2.0) in this project and have made sure any of the zboss code has been guarded however I am still not seeing the correct behavior. Generally using VisualGDB and C++ has not been an issue but its obviously producing something that isn't quite right.

To test further I created a C project in VisualGDB and copied the light_switch example code in. Compiling this project also results in the odd behavior I was experiencing previously.

Seeing as I am using an unsupported IDE I do not necessarily expect support on that front but is there anything else I can look at? Under the hood VisualGDB is using GCC so I would expect that this issue could be a configuration problem.

Possibly relevant info below:

Preprocessor Definitions:
DEBUG=1;XENON;CONFIG_GPIO_AS_PINRESET;ENABLE_FEM;FLOAT_ABI_HARD;NRF52840_XXAA;ZB_ED_ROLE=1;ZB_TRACE_LEVEL=0;ZB_TRACE_MASK=0;

(XENON is a custom board definition for the Particle.io Xenon dev board)

Command Line:
-std=gnu++1z -fno-rtti "VisualGDB\Debug\PCH" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/include/ha" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/include/osif" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/include/zcl" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/include" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/include/zll" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/osif" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/zb_error" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/nRF-IEEE-802.15.4-radio-driver/src" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/nRF-IEEE-802.15.4-radio-driver/src/mac_features" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/nRF-IEEE-802.15.4-radio-driver/src/fem" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/nRF-IEEE-802.15.4-radio-driver/src/raal/single_phy" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/nRF-IEEE-802.15.4-radio-driver/src/raal/simulator" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/nRF-IEEE-802.15.4-radio-driver/src/raal" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/components/libraries/pwm" -I"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/integration/nrfx/legacy" -I"../../../../multi_sensor" -I"../../../Libraries/Bosch/BME280/BME280" -ggdb -O0 -fdata-sections -D"DEBUG=1" -D"XENON" -D"CONFIG_GPIO_AS_PINRESET" -D"ENABLE_FEM" -D"FLOAT_ABI_HARD" -D"NRF52840_XXAA" -D"ZB_ED_ROLE=1" -D"ZB_TRACE_LEVEL=0" -D"ZB_TRACE_MASK=0" -fno-exceptions -ffunction-sections -std=gnu99 "VisualGDB\Debug\" 

Linker Command Line:
-o "H:\Development\VisualGDB\Projects\ZigBeeTemperatureSensor\VisualGDB\Debug\ZigBeeTemperatureSensor" -Wl,-gc-sections -L"../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/lib/gcc" -T"nRF52840_XXAA_zigbee_nosoftdev.lds" "../../../../Tools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/15.2/15.2/nRF5x/external/zboss/lib/gcc/nrf_radio_driver.a" -l"zboss.ed"

Thank you.

RE: Zigbee Sleepy End Device Immediately Sleeps after Joining Network

Jørgen Holmefjord — Fri, 29 Mar 2019 10:19:18 GMT

Hi,

Did you test the original light_control example in the SDK to see if the Sleepy End Device functionality is working as expected there? You can put the light_switch example in sleepy device mode by holding button 3 (BSP_BUTTON_2) when resetting/powering the board.

Best regards,
Jørgen