I'm trying to use nRF5 SDK for thread and Zigbee 3.2.0 on top of FreeRTOS 9.0 for a Zigbee coordinator.Since I could not find any coordinator example on FreeRTOS, I started with adding the files etc as of "Adding dynamic multiprotocol Zigbee support to BLE examples" and followed the init"Zigbee Multi Sensor with FreeRTOS Example" to my current project, but ran in some issue directly when calling ZB_INIT("zdo_zc");
I get the following output from zboss, via zb_osif_serial_put_bytes, after that I get stuck in hard fault.Len:8 Data:0xdead0e0203000000Len:8 Data:0x7a00820f00f8ff07
Any clues or ideas of what I missed?
Dev setup:Win 10gcc-arm-none-eabi-7-2018-q2 FreeRTOS 9.0nRF5 SDK for thread and Zigbee 3.2.0nRF52840-DK
libs:nrf_radio_driver_softdevice.alibzboss.a (debug version)s140_nrf52_6.1.1_softdevice.hex
DefinesSOFTDEVICE_PRESENT S140 RAAL_SOFTDEVICE=1 FREERTOS ZB_TRACE_LEVEL=0ZB_TRACE_MASK=0
It depends on what kind of hardfault is it? it is quite hard to say without knowing your implementation. I have not tried Zigbee with FreeRTOS before but you can debug the hardfault as explained here.
I added ZB_ENABLE_SOFTDEVICE_FROM_ZBOSS=1 since I don't use the softdevice for BLE yet, but i t will be used in the future.
Now I get at stack trace like this:
_exit() at newlibStubs.c:281 0x2dfaa abort() at 0x60ffa __assert_func() at 0x60540 nrf_raal_init() at 0x5fc1e nrf_802154_rsch_init() at 0x5dbee nrf_802154_init() at 0x5b984 mac_nrf52840_hw_init() at 0x3a08a zb_mac_transport_init() at 0x3a0b6 zb_init() at 0x41d6a
Sorry for the late response Vilhelm
The assert does not seem to show anything that tells me that this could cause because of the FreeRTOS port. So this must be Zigbee related assert. With given details, if there is an assert in RAAL, then it most likely could be conflict in interrupt priority ini which zb_init is called. Nothing else strikes me with the given info.
I proceeded a bit when changing priorities, but got stuck again.
My stack trace:
zb_osif_nvram_erase_async() at zb_nrf52840_nvram.c:405 0x28be4
zb_nvram_load() at 0x36186
zb_zdo_dev_init() at 0x3b910
zdo_dev_start() at 0x3baf4
zigbee_main_task() at main.c:511 0x2bc2c
Where I got stuck:
zb_ret_t zb_osif_nvram_erase_async(zb_uint8_t page)
zb_uint32_t flash_addr = 0, i;
zb_int_t ret = 0;
if (page >= ZB_NVRAM_PAGE_COUNT)
TRACE_MSG(TRACE_COMMON3, "zb_osif_nvram_erase_async page %hd", (FMT__H, page));
flash_addr = ZB_NVRAM_PAGE_BASE_ADDRESS(page);
for (i = 0; i < ZB_NVRAM_PAGE_SIZE / ZB_NVRAM_FLASH_PAGE_SIZE; ++i)
ret = nrf_fstorage_erase(
&nvram_fstorage, /* The instance to use. */
flash_addr, /* The address of the flash pages to erase. */
1, /* The number of pages to erase. */
NULL /* Optional parameter, backend-dependent. */
ZB_ASSERT(ret == NRF_SUCCESS);
if (ret != NRF_SUCCESS)
/* This call is designed to be asynchronous, but currently it is synchronous. */
/* Wait SOC event handler with NRF_EVT_FLASH_OPERATION_SUCCESS or NRF_FSTORAGE_ERASE_RESULT */
while (zb_osif_flash_op_progress()) <---- Here is where I got stuck forever
flash_addr += ZB_NVRAM_FLASH_PAGE_SIZE;
Did any of the fstorage items got written or read successfully? or is this this the first flash event that gets stuck. Seems like there seems to be a deadlock condition created by the app you are working that manages to add flash request to the ATFIFO but somehow the thread that makes this request never sleeps/yields. This could cause the thread that needs to pull the events never execute. I am not a Zigbee expert, but these while loop looks dangerous in my opinion which has no time expiry plugged into it