• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 150 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290488
Options
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

Instruction and Data Fault registers

user86158

I am trying to figure out why my application is generating a hard fault. The hardware platform is nRF52832 and SDK is 17.1.0

In my experience, the generic Cortex M3 processor (and most likely the M4 too) has two registers (DFAR and IFAR) that capture the fault address at run time.

The IFAR usually has the address of the instruction that triggered a 'bad instruction' (or similar) error.
The DFAR usually has the address of the innstruction that caused a bad read or a bad write (only for deterministic, ordered sequence?).
I do not see such a register being exposed when I am debugging with the Segger IDE provided by Nordic.

Is there anything I can set up on the Segger IDE, or perhaps use some other tool, that will allow me to view the faulting address?
NOTE that the fault happens when the application is executing multiple threads asynchronously and it is not easy to 'navigate to the faulting address one line at a time in the debugger'.

Thanks

RMV

  • 0

    Just an update..

    I was able to narrow down the root cause of the failure -- through some random trial and error -- that the issue was because I was using two asynchronous and independent schedulers that were completely disconnected and that led to invalid states in my application later on.

    However, I would still like to understand how I can narrow down the offending instruction that triggered an instruction fetch/decode error or a precise/imprecise data access error.

    Cheers

    RMV

  • +1

    Hi RMW

    I found a reference to these registers in the Cortex R4, but I don't think there are any such registers in the M4. 

    I would recommend using the HardFault handling library in the nRF5 SDK, then you will get information about the source of errors. 

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Hi Ovrebekk

    Thanks for the feedback, and yes indeed it is the R4 (and not the M3) as you rightly indicated.

    I will mark my question as answered.

    Cheers

    RMV

Related
Terms of service