This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52840 Hard fault Exception Root cause Tracker

Hi Team,

We are using the NRF52840 with s140 Soft device for our BLE application.

While we are facing some issues while doing debugging.

1. We are getting Hard Fault exceptions, how to know the root cause for those fault, we have checked the call stack, it is not showing any reference.

2. We are unable to put the break points while debugging, it is causing to hit the fault handler followed by Reset , how to do the step over( F10) and step in(F11) debugging.

Is there any way to debug the code with break points without causing reset and how to know the Reset Root cause(attached the error screenshot).

Regards,

Srinivas.V

Parents
  • Hello,

    The softdevice is a very time sensitive module, so you can't pause the project execution while you are doing BLE operations and resume afterwards. If you set a breakpoint, or manually pause the execution, you will need to restart the application before the next softdevice operation kicks in. This basically means that you can use breakpoints, and step a few lines, but then you need to restart the application after this, because when the softdevice realizes that it has missed a lot of timeslots, it will assert.

    I am sorry, but this is the way it works.

    Please note that for development, the NRF_LOG is also a quite useful tool, in addition to breaking and stepping in the project.

    BR,

    Edvin

  • Hi Edvin,

    Thanks for your valuable reply.

    1. Is there any way to find out or know the Root cause or source  for Hard Fault exceptions, or other reset issues, means which function is causing or which instruction is giving the Reset or exception. we have checked the call stack, it is not showing any reference.

    Regards,

    Srinivas.V

  • Probably, yes. But I am not familiar with these kinds of issues. If you stop the execution, and then resume, and later receives a hardfault, then the break in the execution is the issue.

    Most reset issues aren't hardfaults. It is a cool word, but usually not the case. The most common issues are APP_ERROR_CHECK(err_code) receiving an err_code != 0 (NRF_SUCCESS). The best way to know which one is to use logging. If you have enabled the log, it should say "fatal error". If you get this, define "DEBUG" in your preprocessor definitions, and it should give you the file and line number that triggered the error. Then you need to check why the function that returned that err_code returned this value. 

    So does your log say anything? What SDK version do you use?

Reply
  • Probably, yes. But I am not familiar with these kinds of issues. If you stop the execution, and then resume, and later receives a hardfault, then the break in the execution is the issue.

    Most reset issues aren't hardfaults. It is a cool word, but usually not the case. The most common issues are APP_ERROR_CHECK(err_code) receiving an err_code != 0 (NRF_SUCCESS). The best way to know which one is to use logging. If you have enabled the log, it should say "fatal error". If you get this, define "DEBUG" in your preprocessor definitions, and it should give you the file and line number that triggered the error. Then you need to check why the function that returned that err_code returned this value. 

    So does your log say anything? What SDK version do you use?

Children
No Data
Related