This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee SDK on top of FreeRTOS

Hi

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:0xdead0e0203000000
Len:8 Data:0x7a00820f00f8ff07

Any clues or ideas of what I missed?

Dev setup:
Win 10
gcc-arm-none-eabi-7-2018-q2
FreeRTOS 9.0
nRF5 SDK for thread and Zigbee 3.2.0
nRF52840-DK

libs:
nrf_radio_driver_softdevice.a
libzboss.a (debug version)
s140_nrf52_6.1.1_softdevice.hex

Defines
SOFTDEVICE_PRESENT
S140
RAAL_SOFTDEVICE=1
FREERTOS
ZB_TRACE_LEVEL=0
ZB_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

    Any suggestions

    BR

  • 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;
    
      ZVUNUSED(ret);
    
      if (page >= ZB_NVRAM_PAGE_COUNT)
      {
        return RET_PAGE_NOT_FOUND;
      }
      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)
      {
        while (zb_osif_flash_op_progress())
        {
        }
    
        zb_osif_set_flash_op_progress();
        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)
        {
          return RET_ERROR;
        }
        /* 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;
      }
      zb_osif_flash_erase_finished(page);
      return RET_OK;
    }

    Any clues?

  • 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

Related