• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 417 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 233416
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How critical are ASSERT() crashes in the SDK? (with DEBUG_NRF defined)

user15909

Hi,

I recently added the DEBUG_NRF preprocessor definition to my project because I wanted to use the nrf_assert module in some of my files. Now my project is crashing a lot in different places due to not necessarily incorrect behavior.

An example of this is calling an uninit() function of some driver. Those functions do not return errors if you call uninit() when the module is already uninitialized, but they will assert if called with DEBUG_NRF defined.

My question is, should I go out of my way and fix all those errors? Or is it ok to just undefine DEBUG_NRF and forget about them?

Parents
  • 0

    Only you can decide what errors are critical in your particular use case, and whether a reset is an appropriate way to handle them.

    .

  • 0 in reply to user6462

    This is such a cliche answer (more like 'CYA')..... Almost all of the unwanted triggers are in the SDK files and I am pretty sure the average user has no desire to navigate the SDK and figure out if the collective set of all such uses can be safely managed by not defining 'DEBUG_NRF' macro.

  • 0 in reply to user86158

    This is an old case, but ok.

    The ASSERT and ERROR_CHECK type functions are useful tools when developing/debugging. It is useful to determine whether the application logic is correct (e.g. not using a driver that is uninitialized). You can decide whether you want to disable it or not. If you disable it, and your application doesn't work as you intend, you can enable it to get some information to where the issue may be. But if your application is doing a lot of "illegal" calls, such as sending bluetooth messages to a connection that is currently not connected, then that is perfectly fine if your intention is to ignore the return values in these situations. 

    So as says, it depends entirely on your application whether you want to ignore asserts and error checks. Ignoring a return value of a doorbell not connected to the speaker on the inside is more forgiving than ignoring an error return value from a door lock jamming. 

    BR,

    Edvin

Reply
  • 0 in reply to user86158

    This is an old case, but ok.

    The ASSERT and ERROR_CHECK type functions are useful tools when developing/debugging. It is useful to determine whether the application logic is correct (e.g. not using a driver that is uninitialized). You can decide whether you want to disable it or not. If you disable it, and your application doesn't work as you intend, you can enable it to get some information to where the issue may be. But if your application is doing a lot of "illegal" calls, such as sending bluetooth messages to a connection that is currently not connected, then that is perfectly fine if your intention is to ignore the return values in these situations. 

    So as says, it depends entirely on your application whether you want to ignore asserts and error checks. Ignoring a return value of a doorbell not connected to the speaker on the inside is more forgiving than ignoring an error return value from a door lock jamming. 

    BR,

    Edvin

Children
No Data
Related
Terms of service