Custom application error handler, ZigBee

[AnnaR]

I tried to redefine weak app_error_fault_handler by custom one (nRF5 SDK for Thread and Zigbee v2.0.0, Segger Embedded Studio), according to https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fgroup__app__error.html

but there is following linker error:

../../../../../../../../external/zboss/lib/gcc/libzboss.a(mac_nrf52840_driver.o): In function `app_error_fault_handler':

mac_nrf52840_driver.c:(.text.app_error_fault_handler+0x0): multiple definition of `app_error_fault_handler'

 

So, it seems that app_error_fault_handler already redefined in the ZBOSS stack?

Is it possible to use my custom error handler in some other way?

[AndreasF]

Hi.

Firstly, we have a new SDK for Thread and Zigbee out, version 3.0.0, I suggest you use that.

Second, the app_error_fault_handler is indeed defined in the stack, as well as in the SDK. Why would you want to redefine it?

Best regards,

Andreas

[AnnaR]

Hi, Andreas.

Thanks, I know about the newest SDK version, just didn’t yet move the existing project to it.

I would design the robust application (at least, as much as I can), so would prefer to have the control on the error handling, in case I need to add a specific reaction on some errors.

After reading this tutorial devzone.nordicsemi.com/.../an-introduction-to-error-handling-in-nrf5-projects
I thought to use the APP_ERROR_CHECK() with app_error_fault_handler
redefinition.

But appears, if I use ZigBee stack, I cannot redefine app_error_fault_handler for my own (with current SDK and stack versions)? Does it correct?

Maybe, there is another similar "simple" way to use custom error handler exists with the current SDK-stack versions?

Sincerely,

Anna

[AndreasF]

Hi.

I've had a dive in the SDK and the stack to try to find a solution. I've found one, but it is not perfect I'm afraid.

First, just remove your redefintion of app_error_fault_handler. Then try to implement how you would like to handle the errors in the function void zb_nrf52840_abort(void) in the library file external\zboss\osif\zb_nrf52840_common.c.

It is in this function the Zigbee stack will end up after the app_error_fault_handler() is called in the stack. Note that this will affect all your project since it is a modification of a library file.

I hope this works for you.

Best regards,

Andreas

[AnnaR]

Hi.

Many thanks for your reply, I really appreciate your help.

In order to left an original zb_nrf52840_abort(void) function code for other projects, I can use the #ifdef-#else-#endif directives with some define from “target” project.

But unlike app_error_fault_handler, the error-describing parameters are not transferring to  zb_nrf52840_abort function. So in this case, it is known that some error occurred, but unclear, which exactly.

I found another variant, that is far from perfect too, though :)

In the project options, I turned on the “Code > Linker > Allow Multiple Symbol Definition” (by selecting “Yes” value). According to GNU linker docs, this option allows multiple definitions and the first definition will be used.

It works in my case, so linker uses my app_error_fault_handler variant instead of one in ZigBee stack.

However, I concern about stack handler. If they just call the zb_nrf52840_abort function, it’s okay. But what if they realized some important stack-related error “resolvers”, which will not be used if I declare my handler? If it is possible, could you please advise me about it?

Sincerely,

Anna

[AndreasF]

Hi again Anna.

The app_error_fault_handler inside the stack prints the same information as the app_error_fault_handler found in components\libraries\util\app_error_weak.c in the SDK, and then it asserts to zb_nrf52840_abort().

Best regards,

Andreas

[AnnaR]

Hi, Andreas.

Thanks for the clarification!

Sincerely,

Anna