Hello,
We're building zigbee devices around the nRF5340 with the nRF SDK/zboss/zephyr. I'm working on custom boards and have based my 802154 code around the samples in nrf/samples/zigbee.
Though running atop those custom boards, I kept the light_switch and network_coordinator pretty much as-is and was running each on a distinct PCB. Things weren't working out, so I started looking at each component in turn, to finally find this:
In this example, I'm monitoring the network coordinator with a debugger and sniffing zigbee packets over the air. I let it run for a minute and all is well. As soon as I turn on the light_switch, a beacon request is made and crash! A sample of the logs is attached below for reference.
In attempting to trace where the problem lies, I've peppered the nrf/zephyr code with extra bread crumbs. The "zboss_osif: zbooslooop" (typos make it easy to grep ;-) ) before every call to zboss_main_loop_iteration() in the zboss_thread. The "zignetco: DEFHNDL" is from every time the network controller's zboss_signal_handler callback is triggered but just passes the signal along to zigbee_default_signal_handler().
Crashes always seem to happen in the same sequence: a beacon request or whatever commissioning stuff arrives through the aether, zboss main loop triggers my signal handler, which passes it back to zigbee_default_signal_handler() which wants to get the goods from the spinel IPC thing and... death.
I have played with
- CONFIG_HEAP_MEM_POOL_SIZE
- CONFIG_MAIN_STACK_SIZE
- CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE
to no avail. I eventually thought it was my own system stuff, tried to simplify and just use standard vanilla network_controller code on standard vanilla nRF5340DK... that just led me to posting this:
https://devzone.nordicsemi.com/f/nordic-q-a/82962/frozen-zigbee-network-coordinator-sample-on-nrf5340
so no love there, but oddly in that case I can't get anything working at all.
Of course, to not be completely blind in trying to debug all this, I had to disable the default LOG_MINIMAL stuff (not sure what the idea is there, hard to dev without some sort of feedback), and all the interaction between mcuboot and the network processor and I dunno what makes using the serial logging harder to deal with than I care, but I did manage to get the segger RTT debug stuff working--don't know if that has an impact on anything.
For reference, I'm using a relatively fresh codebase, zephyr-sdk-0.13.2 and nrf/VERSION says 1.8.0-rc1 (last commit 053f939f0478b68ba6da4d01f3ebd463c111ee00, Pavel Vasilyev, Dec 2 16:49:27 2021).
Neither my straight port of the network coordinator nor the default code on the default platform are behaving well: people must be using this stuff, I feel like I'm missing something obvious... Any clues as to what's going on, where to look, what to tweak would be appreciated.
