zb_nrf52840_abort function

[abe]

Hello, I developed for my customer, a ZigBee coordinator in last 2019, using nRF5 SDK for Thread and Zigbee v3.2.0.
Now I'm debugging to add one new feature, but some time, during debug, the program stops into zb_nrf52840_abort.

What are the possible causes? How can I trace what is happened?
Thanks for help

Abele

[Edvin]

It looks like in SDK 3.2.0, NRF_ERR_CHECK(err_code) will call ZB_ABORT() if err_code != NRF_SUCCESS (or equivalent for NRF_ERR_CHECK_BOOL()). Please see zb_nrf52840_internal.h line 91 and 92.

ZB_ABORT is a macro for zb_nrf52840_abort, so basically, NRF_ERR_CHECK() will call zb_nrf52840_abort().

Look through your project for (just search for all occurences of) "NRF_ERR_CHECK(" and "NRF_ERR_CHECK_BOOL(", and see which one of these that triggered the zb_nrf52840_abort().

Best regards,

Edvin

[abe]

Hi Edvin
there are many calls NRF_ERR_CHECK and NRF_ERR_CHECK_BOOL, and the ZB_ABORT issue is randomic.
To check all calls needs to spend too much time ...
Could I modify the zb_nrf52840_abort to get info about who has called? (for example print line code and file?)

Abele

[Edvin]

I don't see why it wouldn't be possible to just import the APP_ERROR_CHECK() from the "normal" SDK (non-zigbee SDK) examples. This will print the file name and line number of the APP_ERROR_CHECK() that triggered the error.

Best regards,

Edvin

[Edvin]

Actually, looking at zb_nrf52840_internal.h, you can see that NRF_ERR_CHECK()'s definition is dependent on whether or not DEBUG_NRF or DEBUG_NRF_USER is defined. Try adding either of these as a preprocessor definition, and check if the ASSERT() will print something in the log. At least you should be able to put a breakpoint in ASSERT() -> assert_nrf_callback() -> app_error_fault_handler() on line 51 in nrf_assert.c, to monitor the line num and file_name that triggered the check.

Best regards,

Edvin