How can I distinguish the reason for hardfault?

[MANGO]

• Using SDK 7.2 and S110 7.1

• IDE : IAR 7.1

• Board : PCA10001 (Revision 2 MCU)

Hi, regardless of the example, when I add some codes of my own,

there are some cases when the firmware falls into HardFault_Handler

(or other Handlers such as BusFault_Handler).

Comparing to the situation such as SDK function returns error code,

it is easy for developers to tell what code is the problem.

Whereas when the code falls into HardFault_Handler,

is there a way to identify what cased this problem?

Added : 23, July, 2015

One more thing, do I have to consider the endian?

Since nRF51822-QFAA is based on little-endian,

is [0X2000 32D0] = 0x0001 0000 or 0x0100 0000?

If it's 0x0001 0000 (code instruction at 0x0001 0018), then this means the SoftDevice has caused a HardFault?

In my case, as mentioned above, I use SoftDevice S110 7.1 and SDK 7.2.

This is the Dissembly window.

(If showing the instructions of the SoftDevice is illegal, please notice me and I will edit this part.)

Also, this is a part of the .map file.

  Section            Kind        Address    Size  Object
  -------            ----        -------    ----  ------
"A1":                                       0xc0
  .intvec            ro code  0x00016000    0xc0  iar_startup_nrf51.o [1]
                            - 0x000160c0    0xc0
 
"P1":                                     0x7c00
 
  .text              ro code  0x000160c0   0xf14  device_manager_peripheral.o [1]
  .text              ro code  0x00016fd4    0x28  memcmp.o [4]
  .text              ro code  0x00016ffc    0x64  ABImemset.o [4]
  .text              ro code  0x00017060    0x5c  ABImemcpy.o [4]
  .text              ro code  0x000170bc   0x8cc  pstorage.o [1]
  .text              ro code  0x00017988    0xe0  I32DivModFast.o [4]
  .text              ro code  0x00017a68     0x2  IntDivZer.o [4]
  .text              ro code  0x00017a6a    0x2a  zero_init3.o [4]

Added again : 23, July, 2015

@RK : At 0x00019b5a, it was LDR command.

-Regards

[Susheel Nuguru]

edited.. thanks

[RK]

Well I tried :).

Ok you can see why that crashes, r0 is 0x00000001 (that's also stacked by the interrupt routine at 0x200032D0) and 0x00000001 + 4 == 0x00000005 and that's an unaligned load. On the nRF52 that would have given you a better fault AND a nice error code, except it wouldn't have as that allows unaligned loads unless you turn that off.

So now you just have to work out why the head timer isn't TIMER_NULL but the timer table contains totally bogus addresses like 0x00000001. That shouldn't be too hard.

And now you know how to track 2-level deep stacked interrupts. Painful isn't it.

[MANGO]

Wow, it sure is painful...

I should have read both your answer and the Cortex M0 manuscript from ARM more carefully,

but where did you get these infos?

Like The word after the PC, that's the PSP

, R1 is also stacked by the interrupt routine at SP,

and an unaligned load?

I lack of many basic knowledge of Cortex M0 architecture.

So I was curious that where did you received all these infos.

Also, about the unaligned load, you mean the code loaded from R0 + 0x04 was not even, right?

Always appreciate your help and nice guess.

[RK]

ARMs documentation is awesome, but it's very, very, very, VERY long. All this stuff is in the ARM V6M Reference, which is 600 pages long, the V7 one is 1100 pages long. There's a couple of books, The Definitive Guide to The ARM Cortex M0 (and M3, M4 etc) which are pretty good if you want to get a good understanding, then you can dip into the manual later for the details. Mostly you don't need to know it however.

ARM also has their infocenter which has the same stuff, but indexed and with a few pretty diagrams, probably as part of a similar but different target user manual (the generic user guide). The stack picture is here infocenter.arm.com/.../index.jsp, the PSP register details are elsewhere, you can piece it slowly together.