Zigbee SDK on top of FreeRTOS

RE: Zigbee SDK on top of FreeRTOS

Fayne — Thu, 20 Apr 2023 09:48:08 GMT

Hi,

I would like to know if you have a solution at this problem.
We have exactly the same deadlock at the same position.
We can't change the priority of BLE or ZIGBEE because we haven't any FREERTOS or OS in the product.

And this bug is really important to correct for us.

RE: Zigbee SDK on top of FreeRTOS

WestCoastDaz — Thu, 16 Jan 2020 18:11:20 GMT

vilpih

Did you manage to get this working? I managed to get it working by creating a separate higher priority BLE task. This seems to allow the flash events emitted from the SD to be processed without the ZigBee thread getting stuck.

RE: Zigbee SDK on top of FreeRTOS

Marjeris Romero — Tue, 10 Dec 2019 17:12:29 GMT

Hi Vilhelm,

If you are not planning to use BLE, then starting with the Zigbee multisensor with Freertos example instead and then add the coordinator functionality to the example will be a better approach.

You will have to remove the ZB_ED_ROLE define, change the startup function (use zb_set_network_coordinator_role(channel)) and the zboss signal handler (see CLI example for that) to add the coordinator functionality.

I am not sure why you are getting stucked but I think it has to do with the multiprotocol implementation, as zb_osif_nvram_erase_async is waiting for a nRF SoC event (from nrf_soc.h).

NB! If your goal is to have multiprotocol BLE+Zigbee+FreeRTOS then starting from a FreeRTOS+BLE example will be better, as adding multiprotocol with Zigbee is much easier than choosing appropiate variants of Softdevice handlers, defining sections etc.

Best regards,

Marjeris

RE: Zigbee SDK on top of FreeRTOS

vilpih — Fri, 06 Dec 2019 08:15:28 GMT

Thanks!
I don't like it either, but the code is from the SDK.

RE: Zigbee SDK on top of FreeRTOS

Susheel Nuguru — Thu, 05 Dec 2019 10:54:59 GMT

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

RE: Zigbee SDK on top of FreeRTOS

vilpih — Fri, 29 Nov 2019 15:52:53 GMT

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?

RE: Zigbee SDK on top of FreeRTOS

Susheel Nuguru — Thu, 21 Nov 2019 20:31:12 GMT

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.

RE: Zigbee SDK on top of FreeRTOS

vilpih — Wed, 13 Nov 2019 07:32:11 GMT

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

RE: Zigbee SDK on top of FreeRTOS

Susheel Nuguru — Thu, 31 Oct 2019 08:50:50 GMT

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.