Program enters hardfault after exiting from ZB_ZDO_SIGNAL_SKIP_STARTUP state

[anusha_14]

Hello Nordic support,

I am developing a Zigbee application based on FreeRTOS for a device with coordinator role. I was able to add the Zigbee stack and start the Zigbee task successfully. This is the code in the Zigbee task:

void ZigbeeTask(void * ptr)
{
    zb_ret_t       zb_err_code;
    /* Start Zigbee Stack. */
    zb_err_code = zboss_start_no_autostart();
    
    while (true)
    {
        zboss_main_loop_iteration();
        vTaskDelay(1);
    }
}

When I run the program, I am able to see that it initially enters ZB_ZDO_SIGNAL_PRODUCTION_CONFIG_READY state and then enters ZB_ZDO_SIGNAL_SKIP_STARTUP state. However, once it comes out of the ZB_ZDO_SIGNAL_SKIP_STARTUP  state, the program enters hardfault. On debugging, I can see that it successfully exits ZB_ZDO_SIGNAL_SKIP_STARTUP  state and enters zboss_main_loop_iteration function but not sure what happens next that causes the hardfault.

Could you please provide suggestion as to why the program crashes after ZB_ZDO_SIGNAL_SKIP_STARTUP state? Please let me know if you need additional details regarding my query.

Thanks,

Anusha

[Marte Myrvold]

Hi Anusha,

Have you made sure to use ZigbeeTask and mutex guard when handling all Zigbee stack events?

After calling zboss_main_loop_iteration the stack will start handling stack signals and ZCL callbacks. Since you are using FreeRTOS as well, you must make sure the calls to the stack API are thread-safe, by either doing it in the context of the Zigbee task, or by using mutex guard if they are outside the handler. We have an example for Zigbee and FreeRTOS in our SDK, Zigbee Multi Sensor with FreeRTOS example, which you can use to see how to make sure you are handling the stack in a safe way.

Since the device successfully enters the zboss_main_loop_iteration function the problem seems to be with the main application. It would be helpful to know what your application is doing after the stack has started, especially tasks related to Zigbee, as well as how you handle Zigbee stack signals.

Best regards.

Marte

[anusha_14]

Hi Marte,

Thanks for your response. Yes, I referred to the example and tried to use a mutex as well but didn't help. One more thing to note is that the program runs fine without hardfault if the device role is changed to end device. However, in this case, when it enters ZB_BDB_SIGNAL_DEVICE_REBOOT state, it fails to initialise the Zigbee stack using NVRAM data.

So, I would like to understand if we need to specify the NVRAM data to be loaded at startup?

Thanks,

Anusha

[Marte Myrvold]

Hi Anusha,

Are you certain the role was changed to end device? You should not get the error that it failed to initialize Zigbee stack using NVRAM data on any device other than the coordinator, unless you have implemented a custom handling of ZB_BDB_SIGNAL_DEVICE_REBOOT in zboss_signal_handler In ZB_BDB_SIGNAL_DEVICE_REBOOT, an end device should rejoin a network, or if that fails, it should start network steering, and you should get the error "Unable to join the network, start network steering".

If you do not erase NVRAM after reboot or power-off, it should be able to join automatically using the network parameters stored in NVRAM, so you do not have to specify anything regarding this.

How are you handling network steering on your device? The problem could be when the coordinator opens the network for other devices to join, and that this creates a deadlock. 

Best regards,

Marte

[anusha_14]

Hi Marte,

I get the error when using the default Zigbee signal handler also and if I comment the statement 'comm_status = bdb_start_top_level_commissioning(ZB_BDB_INITIALIZATION);' in ZB_ZDO_SIGNAL_SKIP_STARTUP in zigbee_helpers.c, then no hardfault occurs.

What could be the possible reason for this?

Regards,

Anusha

[Marte Myrvold]

Hi Anusha,

Calling bdb_start_top_level_commissioning with commision mask ZB_BDB_INITIALIZATION will start the BDB initialization on the device. Since your device is a coordinator, the only important step it performs during this initialization is to restore its persistent Zigbee data. It will also check whether it has formed or joined a network, but i t will stop the initialization after this. Since removing that line removes the hardfault, the problem is likely to be related to reading the data from NVRAM. Flash operations require some time to complete, so it is possible you are being interrupted by another task while reading, or that the reading is blocking some other important task.

Best regards,

Marte

[anusha_14]

Hi Marte,

Thanks for this information.

Yes, this seems to be the probable reason because if I uncomment 'comm_status = bdb_start_top_level_commissioning(ZB_BDB_INITIALIZATION);' and set the function ZBal_erase_persistent_storage(true); with argument as true, then there is no hardfault because in this case, it does not need to load the data from NVRAM.

Regards,

Anusha