Why there is different implementation for APP_ERROR_HANDLER

[joel-sc]

Hello,

I'm using the NRF5 sdk v17.0.2 with s140 on the nrf52840,

I would like to know the technical reason why the APP_ERROR_HANDLER definition in app_error.h depends on the DEBUG definition. Indeed APP_ERROR_HANDLER will call either app_error_handler or app_error_handler_bare.

In fact I would like to store (when my firmware is compiled in release so, DEBUG won't be defined) the program counter, line number and filename in a record (non volatile memory, or external flash). The app_error_handler_bare doesn't allow to do that because of its API.

I tried to modify the SDK where APP_ERROR_HANDLER doesn't depend on DEBUG and always call app_error_handler, and it works perfectly (line number, filename and program counter can be retrieved perfectly in the final error handler).

So why there is two kind of implementations ?

Best,

Joël

[Jørgen Holmefjord]

Hi,

Most likely, there are two different functions in order to reduce code size in the release version. The file name, line number, and PC is not usually needed in the release version of the application, and the related code can be excluded in order to save space in code flash. I tested to build one of the examples in the SDK with default code (depending on DEBUG flag), and modified app_error.h to only include the direct call to app_error_handler(), and the difference in size seems to be ~0.8 kB. Not a lot for larger chips, but for chips with small flash sizes (nRF52805/nRF52810/nRF52811), this may have a larger impact on the applications that can fit in flash.

You are free to modify the libraries to suit your needs, if the implementation delivered with the SDK does not work well for you!

Best regards,
Jørgen

[Jørgen Holmefjord]

joel-sc said:

I would not totally agree with this. Imagine your application will crash (APP_ERROR_CHECK raise) in production and thus no debug probe attached, we won't be able to get any useful information about the crash reason. That's why PC would be very useful.

I agree with that, but as there is currently no functionality in the SDK to store the error information to non-volatile memory/flash, you would need a debugger connected or some serial/terminal connection to read out the error information when it occurs.

joel-sc said:

That's usually not a good idea because is will be difficult to get up to date will future SDK version.

That is true, but you would anyway have to modify the library code (or write your own error handler library/functions) to support the storing of error data to flash. 

I'm not sure if you know this already, but nRF5 SDK is currently in "maintenance mode", meaning there will likely not be that many additional releases coming in the future. This also means that we will likely not add new features/improvements, unless it is critical/bugfixes. You can read more about this in this blog post.

[joel-sc]

Hello Jørgen

Jørgen Holmefjord said:

I agree with that, but as there is currently no functionality in the SDK to store the error information to non-volatile memory/flash, you would need a debugger connected or some serial/terminal connection to read out the error information when it occurs.

In fact it is possible because app_error_fault_handler (the function called by the APP_ERROR_HANDLER in debug) is declared as weak. So the first thing I did was override this symbol. Then in debug mode I'm allowed to write the crash log info into a persistent memory area.

Jørgen Holmefjord said:

I'm not sure if you know this already, but nRF5 SDK is currently in "maintenance mode", meaning there will likely not be that many additional releases coming in the future. This also means that we will likely not add new features/improvements, unless it is critical/bugfixes. You can read more about this in this blog post.

Yes, I'm aware and sad...

Anyway I think you're answered to my question. I'll probably patch app_error.h or won't use this macro at all.

Thanks for you time Jørgen.

Best,