Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why there is different implementation for APP_ERROR_HANDLER

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

Parents
  • 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

  • Hi,

    Thanks for your response and for having take time to try it.

    he file name, line number, and PC is not usually needed in the release version of the application,

    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.

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

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

    An idea would be let the user defines it own APP_ERROR_HANDLER like this:

    // in app_error.h
    #ifndef APP_ERROR_HANDLER
    #ifdef DEBUG
    #define APP_ERROR_HANDLER(ERR_CODE)                                    \
        do {                                                               \
            app_error_handler((ERR_CODE), __LINE__, (uint8_t *) __FILE__); \
        } while (0)
    #else
    #define APP_ERROR_HANDLER(ERR_CODE)         \
        do {                                    \
            app_error_handler_bare((ERR_CODE)); \
        } while (0)
    #endif
    #endif

    Thus as a client we could redefine it:

    #if defined(APP_ERROR_HANDLER)
    #undef  APP_ERROR_HANDLER
    #endif
    #define APP_ERROR_HANDLER(ERR_CODE)                                    \
        do {                                                               \
            app_error_handler((ERR_CODE), __LINE__, (uint8_t *) __FILE__); \
        } while (0)

Reply
  • Hi,

    Thanks for your response and for having take time to try it.

    he file name, line number, and PC is not usually needed in the release version of the application,

    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.

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

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

    An idea would be let the user defines it own APP_ERROR_HANDLER like this:

    // in app_error.h
    #ifndef APP_ERROR_HANDLER
    #ifdef DEBUG
    #define APP_ERROR_HANDLER(ERR_CODE)                                    \
        do {                                                               \
            app_error_handler((ERR_CODE), __LINE__, (uint8_t *) __FILE__); \
        } while (0)
    #else
    #define APP_ERROR_HANDLER(ERR_CODE)         \
        do {                                    \
            app_error_handler_bare((ERR_CODE)); \
        } while (0)
    #endif
    #endif

    Thus as a client we could redefine it:

    #if defined(APP_ERROR_HANDLER)
    #undef  APP_ERROR_HANDLER
    #endif
    #define APP_ERROR_HANDLER(ERR_CODE)                                    \
        do {                                                               \
            app_error_handler((ERR_CODE), __LINE__, (uint8_t *) __FILE__); \
        } while (0)

Children
No Data
Related